On Tue, Feb 16, 2016 at 4:12 AM, Pedro Giffuni <p...@apache.org> 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/Package_inc.mk > U main/svx/AllLangResTarget_svx.mk > --- Recording mergeinfo for merge of r1409397 into '.': > U . > Summary of conflicts: > Text conflicts: 1 > Conflict discovered in file 'main/svx/Package_inc.mk'. > 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/Package_inc.mk' > 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: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
