Subversion creates an unnecessary tree conflict when two branches of
a directory are merged. See the transcript below. Since the
contents of the directory do not conflict between the two branches,
it should just add both subdirectories to the directory and not
report any conflict. In my opinion, that should be the default merge
behavior, but there isn't even any way using svn resolve to tell it
to do that! The only thing svn resolve can do is lose the incoming
change.
The unnecessary tree conflict does not always happen, based on I know
not what. But the transcript below seems to be a reliable way to
reproduce it.
This transcript is boiled down to a simple test case. In the real
thing there were too many of these tree conflicts to fix by hand, so
fixing it by hand is not a solution even if I could figure out how to
fix it by hand.
$REPOS is file:/// something.
> svn --version
svn, version 1.7.8 (r1419691)
compiled Dec 12 2012, 14:18:28
> svn mkdir --parents $REPOS/test1/branches/B1/D1/D2/A -m xx
> svn mkdir --parents $REPOS/test1/tags/T1/D1/D2/B -m xx
> svn co $REPOS/test1/branches/B1/D1/D2/A
> echo test > A/test1.txt
> cd A; svn add test1.txt
> svn commit -m xx
> cd ..
> svn co $REPOS/test1/tags/T1/D1/D2/B
> echo test > B/test2.txt
> cd B; svn add test2.txt
> svn commit -m xx
> cd ..
> svn copy $REPOS/test1/tags/T1 $REPOS/test1/branches/B2 -m xx
> svn list -R $REPOS/test1/branches/B1
D1/
D1/D2/
D1/D2/A/
D1/D2/A/test1.txt
> svn list -R $REPOS/test1/branches/B2
D1/
D1/D2/
D1/D2/B/
D1/D2/B/test2.txt
> svn co $REPOS/test1/branches/B2
> cd B2
> svn merge $REPOS/test1/branches/B1
--- Merging r167502 through r167505 into '.':
C D1/D2/A
--- Recording mergeinfo for merge of r167502 through r167505 into '.':
U .
Summary of conflicts:
Tree conflicts: 1
> svn status
M .
! C D1/D2/A
> local delete, incoming edit upon merge
Summary of conflicts:
Tree conflicts: 1
> ls D1/D2
B/
Note: ls D1/D2 should say A/ B/ and there should be no tree conflict.
In the real thing, the svn status explanation of the tree conflict is
usually "local add, incoming add upon merge." I can't explain why
the simple test case says local delete instead. I don't know if this
matters.
I can't say that Subversion is not behaving according to the
documentation, because the documentation at http://svnbook.red-
bean.com/en/1.7/index.html is extremely vague about this aspect of
Subversion. But it's not behaving in a useful way.
Environmental data:
operating system - Red Hat Enterprise Linux Server release 5.3 (64
bit). Also fails in RHEL 5.5.
The release and/or revision of Subversion - 1.7.8
The compiler and configuration options you built Subversion with -
downloaded from Collabnet, I did not build it
Any private modifications you made to your Subversion - none
The version of Berkeley DB you're running Subversion with, if any -
using FSFS
Anything else that could possibly be relevant. Err on the side of too
much information, rather than too little. - I can't think of anything
else.
I hope this bug report is useful to you. I can't wait for a fix, so
I am changing to a different strategy that does not depend on
Subversion merge.
--Dave Moon
Received on 2013-01-15 00:11:29 CET