Can Subversion handle merges in both directions correctly (branch branch & # 8596;)?

Question

As far as I understand, the most common (and recommended) way to handle branching and merging in Subversion is:

• create a branch as a copy of trunk
• Do subversive development on the branch and regular development on the torso
• In doing so, regularly merge the branch changes → branch to avoid too much discrepancy. With merge tracking ( svn:mergeinfo ), I can simply run svn merge ^/trunk , and SVN will automatically select all unrelated changes from the trunk.
• Once the branch is completed, merge everything back (on trunk: svn merge --reintegrate ^/branch/foo ), then drop the branch.

(described, for example, in the book SVN, chapter Main Merge ).

Now my problem is: although this works well for "feature branches", sometimes "release branches" are also needed, which are submit / release for submitting versions.

With release branches, in my experience, merging should happen in both directions:

• Bug fixes from the release branch should be merged into the trunk (branch → trunk)
• but sometimes a bug fix from the trunk (or even a new feature) is considered critical for the release version (or update for the release) and therefore needs to be combined with trunk → branch

I did not find anything solid in how SVN and svn:mergeinfo deal with this. Can I merge in both directions ("bidirectional merge") and still have svn track merged versions?

Are there any pitfalls? Anything special you need to pay attention to?

Answer 1

Can I merge in both directions ("bidirectional merge") and still have svn track merged versions?

Yes, you can combine individual functions (by merging specific versions), and SVN will track this.

Answer 2

In fact, merging in both directions in SVN often causes much pain (compared to git). The problem is that if you merge trunk into a branch and then try to merge changes on the branch back to trunk, SVN will try to merge changes from the trunk that will be merged into the branch again, which will cause a lot of unnecessary conflicts. To work around this problem, you can only “write” the commit (s) where you merged the trunk into a branch before merging the branch into a trunk. See “Enhanced Merge - Lock Changes” in the SVN chapter for a general approach (but the example they provide does not apply to a specific use case).

Example:

• Suppose your merging of a trunk into a branch created two commits r3857 and r3858 (I see that often when using NetBeans it first creates directories and then files).
• Then you made some additional corrections in this release branch.

• Now you want to combine it back into the trunk. Before doing this, complete the following steps in your trunk directory:

  svn merge "^ / project / branches / release-0.1" -r3857: 3858 -record-only

• After this merge from the release-0.1 branch as usual. This will result in fewer conflicts compared to a direct merge attempt.

• Before making transactions, I sometimes return some of the changes made (in particular, SVN may for some reason enter svnmerginfo at the file level for resolved tree conflicts).