Why do we need to recreate subversion branch after it is merged to trunk? Can we use subversion merge --record-only option on branch now to keep it alive (with subversion 1.6)?

At the moment we are using a lab/test svn area which sits on trunk and has main components of work branched. A branch create or sync to branch or merge from branch to trunk involves doing the operation on each component. I use a script to help do extras around svn merges. After I merge branch components are re-created from trunk again.

http://www.userfriendly.org/cartoons/archives/02dec/uf005016.gif

Other lesser beings are doing svn merges manually, often copying updated files directly and placing in trunk by-passing or skipping svn. Hmmm. Yerch! This is not recommended. It only works okay so long as files have only changed on branch and not on trunk.

Anyway.

I learned that re-creating branch was required after once not re-creating branch from trunk but carrying on work. Next time merge was needed svn merge-tracking did not work well and a normal merge resulted in a mess of conflicts through trying to apply duplicate revisions. I had to use log on branch and do merge of branch changes in sequence to trunk kind-of skipping branch syncs (handling any conflicts resolved manually). . . . For each component. . . . Not quite as nasty as it could have been but including of all changes done in past syncs from trunk was not guaranteed. Anyway. Again. It was a nasty enough experience to persuade me that re-creating branch after merge was really quite a good idea.

Back to now, well, back to merge to trunk and recreate of branch components I did yesterday.

Here is what I do to re-create branch for one component:

BRANCHTAG=insert_appropriate_branch_tag
SVNROOT="insert_appropriate_svn_root"
MODULEPATH=path/in/svn/to/MODULE1

svn_switch_components_to_branch $BRANCHTAG

cd MODULE1
mkdir branch_revfiles
cp -p special branch things branch_revfiles/
svn rm -m"rebranch $BRANCHTAG from trunk" $SVNROOT/branches/$MODULEPATH/BRANCH_MODULE1_$BRANCHTAG
svn cp -m"rebranch $BRANCHTAG from trunk" $SVNROOT/trunk/$MODULEPATH $SVNROOT/branches/$MODULEPATH/BRANCH_MODULE1_$BRANCHTAG
svn up
cp -p branch_revfiles/* .
svn ci -m"rebranch $BRANCHTAG from trunk restore branch rev files" special branch things
rm -rf branch_revfiles

So, anyway, WHY do we need to re-create branch after it is merged to trunk?
Do we still have to re-create branch? Can we use svn 1.6 --record-only ?

Why? Answer: Because ...

http://stackoverflow.com/questions/102472/subversion-branch-reintegration

Subversion 1.5
"it is not recommended to merge from branch to trunk after reintegration. You can find a full discussion about the reason for that, here: Subversion merge reintegrate"
http://blogs.collab.net/subversion/2008/07/subversion-merg/
"Basically, it says, that it is possible to merge your changes again to the trunk, but since reintegration forces you to merge from trunk to branch prior to the reintegrate operation you'll be facing Reflective/Cyclic Merge which is very problematic in Subversion 1.5. According to the article, it is recommended to delete your reintegrated branch immediately after reintegration and create a new one with the same (or different) name instead.
This is a known Subversion behavior which will be addressed in future version (probably in 1.6)."

What I take from the 1.5 Subversion merge reintegrate blog entry:

1. Merging from regularily sync'd branch to trunk called reflective or cyclic merge.
Merge has to take into account branch changes + sync'd conflict changes.
That part of svn merge algorithim has worked using revision tracking for svn 1.5 and earlier and sometimes gets confused.
Okay, we know that, bug "reflective" and "cyclic" are not terms I have familiarity with.

2. svn merge --reintegrate url . is just a 2 URL merge with some additional sanity checks
Have used this type of merge before + manual work to resolve conflicts a good bit in the past.
There are especially awkward merge problems with some cases for mergeinfo and for renamed files.

"An important thing to point out, and I am not sure if the documentation currently does, is that once a branch is reintegrated, it should really be deleted."


What version are we using now?
i@i$ svn --version
svn, version 1.6.12 (r955767)
   compiled Jun 21 2010, 14:15:05

j@j$ svn --version
svn, version 1.6.12 (r955767)
   compiled Jun 21 2010, 16:00:59

"Does anybody know if the reintegrate problem was resolved in Subversion 1.6 ?" – bradhouse Jul 27 '09 at 23:39
"I've addressed svn v1.6 in stackoverflow.com/questions/3309602. The short version: Yes, you can reintegrate multiple times. :)" – Andres Jaan Tack Jul 22 '10 at 22:04
http://stackoverflow.com/questions/3309602/subversion-branch-reintegration-in-v1-6

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
Keeping a Reintegrated Branch Alive

From stackoverflow:
"svn merge --reintegrate , as you would normally. (=> rM)
svn merge --record-only -c M ^/ . Note the record-only option.
Step 2 essentially tells the topic branch to consider the merge commit (revision M, from step 1) part of its history. This merge-revision is the one that usually causes problems during reintegration; svn tries to undo rM when integrating topic a second time.

So, repeated reintegration works, just not automatically. :)"


so:
1. svn merge --reintegrate #as you would normally. (=> rM)
2. cd branch area; svn up; svn merge --record-only -c ^/ . #Note the record-only option.
cherry-pick merge the branch merge to trunk back onto branch


Further reading:
http://subversion.apache.org/docs/release-notes/1.5.html
http://subversion.apache.org/docs/release-notes/1.6.html
http://subversion.apache.org/docs/release-notes/1.7.html
http://subversion.apache.org/docs/release-notes/1.8.html *not released yet*

2010-02-17 — Subversion becomes Apache Subversion
2009-11-07 — Subversion joins Apache Incubator