Subversion branch reintegration in v1.6 [duplicate]

Question

Per this old question, 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." Was that the case? Is it fixed? Can I reintegrate multiple times?

Salify

Let's be more specific. For the purposes of this question, I don't care whether I should be reintegrating. That's a different question. For now, I want to know how to reintegrate multiple times. – Salify

Yes, it was fixed in Subversion 1.8. – Kandi

Answer 1

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.

Salify

They eventually added this to the docs: svnbook.red-bean.com/nightly/en/… – Your

Holy crap. That explanation would have been so much easier to parse. I've added it to the answer. A+ – Salify

Can this handle merging from trunk into the branch (as well as vice versa)? I.e., --record-only the trunk->branch merge as well? – Transubstantiation

Answer 2

Yes, you can. The problem you ask about was solved in Subversion 1.8.

Beginning with SVN 1.8, --reintegrate option is deprecated and reintegrate merges are now performed automatically (or automagically :) ). See Subversion 1.8 Release Notes and read updated SVNBook 1.8 | Reintegrating a branch chapter:

If you choose not to delete your branch after reintegrating it to the trunk you may continue to perform sync merges from the trunk and then reintegrate the branch again. If you do this, only the changes made on your branch after the first reintegrate are merged to the trunk.

...

Only Subversion 1.8 supports this reuse of a feature branch. Earlier versions require some special handling before a feature branch can be reintegrated more than once. See the earlier version of this chapter for more information: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

IMPORTANT: You should upgrade your Subversion client and server if you still use Subversion 1.7 or older. The current and best version of SVN is 1.9 as of year 2016. There is no real reason to be using very old Subversion releases such as 1.5, 1.6 or even 1.7. There were numerous improvements on client and server side since version 1.6!

Kandi

Answer 3

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.

Castorena

@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 svnbook.red-bean.com/en/1.5/…). Free free to browse the release infos for SVN 1.6 (subversion.apache.org/docs/release-notes/1.6.html and svn.apache.org/repos/asf/subversion/tags/1.6.12/CHANGES) for anything rendering this information stale. – Castorena

"I don't think you can..." isn't very credible. An example, an updated reference, something that isn't a book on v1.5... – Salify

@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. – Castorena

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. – Salify

@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. – Pella

This post is the svn merge bible for me and may shed some light: blogs.open.collab.net/svn/2008/07/subversion-merg.html While 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. – Pella

@Andres: What you describe is not reintegrating, it's cherry-picking bugfixes. – Castorena

@Castorena 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. – Salify

@Castorena Actually, you're right, you can do what I'm describing with cherry-picking. However, that was not the question. :) – Salify

@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.) – Castorena

@Joshua McKinnon: Your SVN merge bible is now a 404. – Strophanthin

@PeterMortensen link rot :( blogs.collab.net/subversion/subversion-merg seems to be the new URL - however, I should note - as reintegration is now automatic in SVN 1.8+ so the post may be growing a bit out of date. (See: subversion.apache.org/docs/release-notes/…) – Pella