tags:

views:

399

answers:

2

Per this old thread, using svn 1.5, reintegrating a branch multiple times is problematic, and should be avoided.

There has been some rumbling to the effect that, "This is a known issue, and should be fixed in svn 1.6." Does anyone know whether that was the case? Is it fixed? Can I reintegrate multiple times?

+1  A: 

While 1.6 did indeed fix issues with merge tracking, I don't think you can re-use an integrated branch.

But this is not an issue. Since the branch got fully integrated into the trunk, just delete it and create a new branch (with the same name) in its place.

sbi
Any references?
Andres Jaan Tack
@Andres: How do you propose I find references that a certain thing (the ability to repeatedly reintegrate) does _not_ exist? The SVN book 1.5 says reintegration renders a branch useless (at the end of http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchemerge.basicmerging.stayinsync). Free free to browse the release infos for SVN 1.6 (http://subversion.apache.org/docs/release-notes/1.6.html and http://svn.apache.org/repos/asf/subversion/tags/1.6.12/CHANGES) for anything rendering this information stale.
sbi
"I don't think you can..." isn't very credible. An example, an updated reference, something that isn't a book on v1.5...
Andres Jaan Tack
@Andres: So all this just to avoid an `svn delete`, followed by an `svn copy`. What does it buy you? I have no idea why you're so worked up about it.
sbi
Delete+copy doesn't work for a maintenance branch. Suppose I have a mainline (trunk) and a 1.0 branch. I don't want _most_ of the things in the trunk, but I certainly want to forward-propogate v1.0 bugfixes. This calls for repeated reintegration of one of the branches.
Andres Jaan Tack
@Andres - I think you are confusing simple merging and reintegration. In a release branch (1.0) forward propagating bug fixes to trunk is fine, this does not require reintegrating the branch - It is simply a merge of certain revisions.
Joshua McKinnon
This post is the svn merge bible for me and may shed some light: http://blogs.open.collab.net/svn/2008/07/subversion-merg.htmlWhile 1.6 did some cleanup on cases that mergeinfos are created, I don't think it alters how --reintegrate merges work. You typically only reintegrate feature branches. The rest are plain old merges, tracked fine by both 1.5 and 1.6.
Joshua McKinnon
@Andres: What you describe is not reintegrating, it's cherry-picking bugfixes.
sbi
@sbi Not if the changes go both ways. Like I say, I don't want _most_ of the trunk. That's not to say I don't want _any._
Andres Jaan Tack
@sbi Actually, you're right, you can do what I'm describing with cherry-picking. However, that was not the question. :)
Andres Jaan Tack
@Andres: And the question is fully answered with "you don't need to be able to continue using a reintegrated (feature) branch, just create a new one". (And, BTW, while certainly _unnecessary_, I don't see why this should not be _possible_ to do with a release branch.)
sbi
+5  A: 

To merge a branch topic into the trunk repeatedly: Do the following on every merge.

  1. svn merge --reintegrate <topic> <trunk>, as you would normally. (=> rM)
  2. svn merge --record-only -c M ^/<trunk> <topic>. 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. :)

I eventually found this solution through an enlightening commit message to the svn source and the matching test (search for "def multiple_reintegrates"). This is a "clever trick" discovered and used by svn-devs with the current releases. It's even been added to more recent documentation. The result is still not as good as a DVCS's merging properties, but it's at least functional.

The only broad downside (as per an open issue as of June 2, 2010) is that apparently the svn log -g output is messy. I guess this is the risk.

Andres Jaan Tack
They eventually added this to the docs:http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
JW
Holy crap. That explanation would have been so much easier to parse. I've added it to the answer. A+
Andres Jaan Tack