On Tue, Jan 15, 2013 at 10:32 AM, David Moon <david.m...@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 ]]]
