openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: How to work with the gbuild branch in SVN?
Date Wed, 17 Feb 2016 17:12:06 GMT
On Tue, Feb 16, 2016 at 4:12 AM, Pedro Giffuni <> wrote:
> Hi Damjan;
> The key lies in "svn merge". You may lose part of the history but
> most of it should survive in form of mergeinfo.
> A while ago I documented how to work with branches somewhere in
> cwiki (based on FreeBSD's svn primer). An executive summary:
> - Do a sparse check out of the root AOO tree so you get the
> root of the tree but the branches do not spend space in
> your harddisk.
> - cd to trunk (or the branch) where you will be doing your merging.
> - You should have the complete tree "svn up --set-depth=infinity"
> for the main tree where you will merge the changes.
> - "svn merge" the revision(s) that you need refering to the relative
> tree for the branch you are merging. It's probably easier to do
> this one by one resolving conflicts as you go.
> Example:
> (I already did the sparse checkout + the complete checkout of
> main in my tree).
> % pwd
> /home/pfg/aoo/trunk
> % ls ../branches
> AOO34           alg             l10n40          pfg
> AOO400          capstone2013    ooxml           sidebar
> AOO401          gbuild          ooxml-osba      win8build
> AOO410          ia2             patch-hsqldb19  writer001
>  % svn merge -c r1409397 ../branches/gbuild .
> --- Merging r1409397 into '.':
> C    main/svx/
> U    main/svx/
> --- Recording mergeinfo for merge of r1409397 into '.':
>  U   .
> Summary of conflicts:
>   Text conflicts: 1
> Conflict discovered in file 'main/svx/'.
> Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
>         (mc) my side of conflict, (tc) their side of conflict,
>         (s) show all options: tc
> Resolved conflicted state of 'main/svx/'
> Summary of conflicts:
>   Text conflicts: 0 remaining (and 1 already resolved)
> ..
> (fix, merge next type of fun)
> ___
> Hope that helps,
> Pedro.

Thank you. When do you commit in this process though? The gbuild
branch and trunk have diverged a lot: I count 135 commits in the
gbuild branch that need to be merged. Do I merge and immediately
commit one at a time, totalling 135 commits, possibly leaving trunk in
a broken state until future commits fix it, or do one enormous commit
of all 135 changes from the gbuild branch? Also who do I credit in
"Patch by:" when I have to make changes to get the patch to apply?

I've also been trying the opposite: merge all 4 years of SVN history
from trunk to the gbuild branch, so any problems can be resolved there
before merging it back to trunk, however it seems I get a random and
incomplete mixture of commits applied.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message