Svn merging trunk and branches

Question

I have a huge project.

I need to make a branch - this will be version 2 of the project, but I also need to keep the trunk and change it in parallel with the branch 1 as bug fix to the version 1.

I need to merge bug fixes from the trunk to the branch 1 while adding new features to the branch.

At the end I need to merge all changes back in the trunk and make new tag from it.

So I need bug fix for version 1, new branch for version 2 and of course merging bug fixes in the version 2.

I am using svn but the svn makes problems all the time. I cannot merge anything without conflicts.

Can someone give me an advice what to do?

Regards

Pianissimo

Answer 1

Creating a branch for the purpose of providing bugfixes to older version is called a release branch. You should develop the bug fixes on trunk (because they need to go in all new versions right?). From there you merge them back to the versions that are still supported. That means that when version 1 is no longer supported, you stop merging bug fixes back to it. See the documentation for more info.

If a bugfix in trunk cannot be merged to the branch(es), the solution is to create a 'backport branch'. Here you either partially merge the fix from trunk, partially rewrite the same fix if the code is too different. It's also suggested to record the merges you would normally perform to fix the problem, so merge tracking helps you see wether or not the problem was fixed.

If you're fixing /branches/1.2.x, the naming convention the Subversion project uses is to create a backport branch called 1.2.x-r[REVNUM], where REVNUM indicates the revision you're backporting, or 1.2.x-issue[ISSUENUM], where ISSUENUM indicates the issue you're fixing.

When you're done creating the backport fix, you can merge it to the release with

svn checkout .../branches/1.2.x myproduct-1.2.x
svn merge --reintegrate .../branches/1.2.x-r123 myproduct-1.2.x

After reintegrating the branch, the branch should be deleted.

Rugg

Answer 2

You should first have created a "tag" for your version 1, which is a released version of your product. Version 2 of the project will then be a continuation of the trunk, not a version 2 branch. The only reason you would need to create a branch is to make bug fixes to the (relesed) version 1. Everything you do for the new version would be done at the trunk, unless you have reasons not to.

Unanimity

I have tried this. But the problem remains. We have again a branch for bug fixes and a trunk for new features. Merging bug fixes for release 1 into version 2 - the trunk will result in a lot of conflicts. The svn cannot merge single file without conflicts. Solving the conflicts by hand can make a lot of problems and time waist. Merging with reintegrate does not help! I am wondering how other companies solves this - bug fixing, new version and merging this both? It seems that svn is not good for this king of work. – Pianissimo

Answer 3

First and foremost I suggest you have a look at the SVN documentation as suggested by @SanderRijken and see what feature and release branches are.

But by the sound of your question I assume your main problem is a different one. Namely that no merge at all is "working" (i.e. all give conflicts where you would not expect them). So maybe you could elaborate what you are doing exactly (like post the command you use for merging)?

Sweeps

Answer 4

After merging changes from the trunk into a branch I find it best to merge the branch back into the trunk using the 2-URL merge. As far as I understand --reintegrate it is just a simpler syntax for the 2-URL merge which sometime fails (though I last used reintegrate in version 1.5).

svn merge url://trunk@mergedRev url://branch@HEAD .

Where mergedRev is the revision when you last merged the trunk into the branch.

If you use the simple merge instruction all changed that you merged from the trunk into the branch will be seen as changed that need to be added to the trunk when merging back. The first url in the 2-URL merge tells svn which changes came from the trunk. This should greatly reduce the conflicts during merging.

As for the structure of your repository I can suggest a blog entry (see below since I'm only allowed to use one link in my post) from ariejan.net

blog entry: ariejan.net/2006/11/24/svn-how-to-structure-your-repository/

Lakesha