Thanks a lot for you useful responses!
On Tue, Apr 26, 2011 at 7:24 PM, Ryan Schmidt <
> 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
> > 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
> > The command we are using is something like this: svn merge branch_at_HEADtrunk@HEADWorkingCopyWhereTrunkWasCheckedOut
> 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
Sorry for not be clear. We meant that you pointed.
> 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.
Yeah, that is what we did wrong. We follow your advices and it works as
expected. After lots of documentation reads we did not understand correctly
properly this part but you make this clear to us. Thanks a lot again.
> 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/mybranchworkingcopyoftrunk
> "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
> "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
> 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 will proceed as you marked on future merges.
> > 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-27 09:05:12 CEST