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
intent.
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