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

Re: Subversion merge creates bogus tree conflicts

From: Ben Reser <ben_at_reser.org>
Date: Tue, 15 Jan 2013 11:16:00 -0800

On Tue, Jan 15, 2013 at 10:32 AM, David Moon <david.moon_at_versata.com> wrote:
> I assumed, perhaps incorrectly, that svn knew the difference between
> something being deleted and something never having existed. In other words,
> if the directory had existed and then been deleted or moved, the list of
> changes being merged would have included a delete. But if the directory
> never existed before it would not be mentioned in the list of changes being
> merged.

Julian was trying to suggest the following scenario.

B1 and B2 are related branches.
B1/A/test.txt and B2/A/test.txt exist
B1 deletes A
B2/A/test.txt is changed
You now merge B2 back onto B1.

The delete is not among the list of changes being merged. Since the
list of changes being merged are coming from B1.

There are a couple of potential solutions we could recreate A and
test.txt, we could also ignore everything in A. But we can't make
really make a decision for the user because we don't really know their

What's going to happen right now in this case is a tree conflict. As
should be obvious from this thread, we don't have resolution of tree
conflicts handled very well yet. What we should ultimately gain here
is an interactive resolution of the problem much as we've gained for
file conflicts, where you can choose one of the resolutions.

Here's the same as above just as a script to demonstrate:
svn mkdir --parents $REPOS/test1/branches/B1/A -m xx
svn co $REPOS/test1/branches/B1
echo test > B1/A/test.txt
svn add B1/A/test.txt
svn commit -m xx B1
svn cp $REPOS/test1/branches/B1 $REPOS/test1/branches/B2 -m xx
svn co $REPOS/test1/branches/B2
echo test2 >> B2/A/test.txt
svn commit B2 -m xx
svn co $REPOS/test1/branches/B1
cd B1
svn rm --force A
svn commit -m xx
svn merge -r0:HEAD $REPOS/test1/branches/B2
Received on 2013-01-15 20:16:42 CET

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

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