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

Re: SVN 1.5.1 merge issue with new files

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 27 Aug 2008 09:07:07 -0400

On Tue, Aug 26, 2008 at 2:51 PM, Thomas Weise
<thomas.weise_at_efrontier.com> wrote:
> SVN 1.5.1 does not handle a merge scenario (reports a conflict) where a
> new file is added to trunk, then merged to a branch, then modified in
> the branch and then merged back to trunk.
> The merge back to trunk fails with a conflict when using svn merge with
> no additional options.
> With the-reintegrate option the correct merge/update occurs instead.
> Please find the console log below. My expectation was that merge should
> handle this case w/o additional options. It looks like a bug. Even if
> there was no common ancestor or merge info, the change itself is not a
> conflict, just comparing the two files should be sufficient to merge.

The scenario you outline is the exact case where you are supposed to
use --reintegrate. Specifically, you can expect that you need to use
--reintegrate anytime you want to merge a branch back to the place
from which is was originally created. To be completely precise
though, you only really need to use --reintegrate in this scenario IF
you also performed at least one merge to the branch from the source
location. You did this in your example in r5. Once you have done
that merge you have created a "reflective" or "cyclic" merge scenario
and you must use --reintegrate when merging the branch back to the

Mark Phippard
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-27 15:07:33 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.