What is the correct way to handle re-merges of an SVN branch?

Question

Here we have an SVN repository with a trunk and branch for development in the new version.

In the near future, the branch is ready for release, so I decided to reintegrate the branch back into the trunk. Obviously, there were some conflicts. Including quite a few tree conflicts from files that were deleted in the trunk.

I resolved all the conflicts quite happily and handed over the chest.

The problem is that we made a few minor changes to the branch, so I started to reintegrate the branch again and the same tree conflicts arose. Solving them is not a problem, but there are quite a few of them, and it takes some time to verify and resolve them, and I don’t want that every time I make changes and reintegration, I don’t want to go through the same resolution processes. I expected SVN to know that the branch has already been reintegrated once and only merged with the point at which the last reintegration occurred.

When I open the revision chart, it shows the connecting line and the point at which the branch was split, but it does not show a merge. Should he?

Server: WinServer2003 (R2sp2), VisualSVNServer (1.7.2). Client: WindowsXP (sp3), I use TortoiseSVN (1.6.5) to do all this, but I also have a command line client installed.

I am merging, making sure that I have the trunk up to date, and using TortoiseSVN to merge, and I select "Re-integrate branch" when presenting the options dialog box. I set the merge depth to "Working Copy"

Am I handling this script incorrectly? Should I do something different?

(Maybe we have the wrong repository layout. We separated from the chest, made all the changes for the new version in the branch, now the release is due to the fact that we are merging the branch back into the trunk. Perhaps this is the wrong approach, I read that some people do it the other way around, make all the changes in the trunk and make a branch only when you are almost ready to release, and the branch becomes a supported version of the release)

Answer 1

At the end of this chapter of the SVN book:

In Subversion 1.5, when the -reintegrate merge is performed from branch to trunk, the branch is no longer suitable for further work. He is not able to properly absorb new changes in the chests and cannot be reintegrated into the trunk again. For this reason, if you want to continue working with your function branch, we recommend that you destroy it and then recreate it from the trunk

Answer 2

In this situation, I would not merge the code from the branch into the trunk until you completed the development.

I would merge with trunk to branch so that your branch is updated with any corrections applied to the trunk. Perform this operation periodically to ensure that the dev branch contains all the fixes. Then, at the moment when development becomes a live release, merging occurs from branch to trunk as a single action.

My answer contains several assumptions, including:

• You have a live trunk and dev branches
• You only have one live version (i.e. not saving an obsolete version)

Hope this helps.

Answer 3

Currently, re-bidirectional merging is actually possible

A word of caution. This answer explains how this should be done, but if you skip any step, you will be sorry. For example, merging -reintegrate merge should be completely trivial (all differences are already resolved in the branch), because otherwise you will not receive the slightest missed changes that you made in the -reintegrate merge step when you continue to work in your branch. An alternative is to delete and re-create the branch every time after - reintegration.

---

In at least svn version 1.6 and later, you can re-do bidirectional merge. You can merge from the "main" branch into the child branch as many times as you like, only with svn merge, but each time you merge the branch to the main one, you must specify the option

- reintegrate as indicated in other answers.

What you also need to do is tell the branch that you integrated it in the second step manually (with checking and updating the branch) with the command

svn merge --record-only -c 391 ^/calc/trunk 

391 here represents the merge commit number from the -reintegrate branch commit command you just made in calc / trunk.

If you skip it, it may still work, or you may need to re-resolve the merge conflicts that you already resolved the next time you merge. After the write-only phase, your branches are ready for further work or merging. This is stupid (especially if you are spoiled by Git , like me, where everything works), but if you do it in accordance with this ritual, it works, and both branches are always open for new commits.

---

All of this is documented in the SVN book under reintegrate twice.

This merge uses the cherry merge syntax that was introduced in the Scherpil section. Continuing the work is an example from the “Reintegration of a Branch” section, where Version X was revised 391:

 $ cd my-calc-branch $ svn update Updating '.': Updated to revision 393. $ svn merge --record-only -c 391 ^/calc/trunk --- Recording mergeinfo for merge of r391 into '.': U . $ svn commit -m "Block revision 391 from being merged into my-calc-branch." Sending . Committed revision 394. 

Now your branch is ready to absorb changes from the trunk again. After you synchronize your branch with the trunk again, you can even re-integrate the branch a second time. If necessary, you can do another write-only merge to keep the branch alive. Rinse and repeat.