[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems merging two branches - Subversion 1.3

From: Ryan Schmidt <subversion-2011a_at_ryandesign.com>
Date: Tue, 26 Apr 2011 12:24:19 -0500

On Apr 26, 2011, at 11:47, Jonatan Soto wrote:

> We are facing some problems during a merge process from a branch to trunk (2 URL merge). Note that we didn't synch the branch with the trunk at any time.
> We want apply all changes made in that branch back to the trunk but for some reason the results that are we getting are very odd. Lots of files are not merged nor added and for some strange reason all conflicts are tree conflicts.
> The command we are using is something like this: svn merge branch_at_HEAD trunk_at_HEAD WorkingCopyWhereTrunkWasCheckedOut

Before Subversion 1.5, it did not track merges for you; you must track merges yourself.

First, I assume where you write "branch" and "trunk" you actually mean the complete URL to the branch and the trunk, such as http://www.example.com/svn/branches/mybranch and http://www.example.com/svn/trunk.

This merge is not correct. You've asked Subversion to compute the steps necessary to convert the head of the branch into the head of the trunk, and to apply those steps to a working copy of trunk. This doesn't make sense and is not the right thing to ask Subversion to do.

Instead, you need to ask Subversion to compute the steps to convert the branch as it was when you created it, into the branch as it is now, and apply those steps to the trunk working copy. The command to do that is:

svn merge -rA:B http://www.example.com/svn/branches/mybranch workingcopyoftrunk

"A" should be the revision when this branch was created. You can use the following command to determine this revision:

svn log --limit 1 -r 1:HEAD --stop-on-copy http://www.example.com/svn/branches/mybranch

"B" should be the current head revision, or the last changed revision of the branch, as you wish.

You'll then have to resolve conflicts in the working copy, if there are any.

When you commit this working copy, your commit message should state what range of revisions you just merged, so that if you need to merge again later, you'll know what revisions to include -- don't merge the same revisions twice. This means if you do merge a second time, "A" won't be the revision when the branch was created, but will be the revision after the last one that was already merged.

> We know that the --reintegrate option is only available since version 1.5 and perhaps it's the right thing to do, but we cannot upgrade subversion, it's out of our scope and impossible to accomplish.

Understand that the current version of Subversion (1.6.x) and the preceding one (1.5.x) are supported; earlier versions are not.

Received on 2011-04-26 19:24:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.