On 10/15/2014 01:23 AM, Philip Martin wrote:
Checked the issue using SVN trunk. It does not abort like 1.8.10, but
it does report tree conflicts for d1/f1 and d1. I would say such
conflicts should be resolved automatically, given that the working
copy contains exactly the same changes as in the incoming
edit. Figuring that out may not be trivial, though, as the copied
directory may be arbitrarily deep.
The difficulty here is that Subversion does not know that the repository
tree was created as a commit from this working copy. Resolving the
tree-conflicts automatically probably needs more complete move-tracking.
I think this kind of conflicts happens with plain deletions as well. I
don't have a trunk Subversion available right now to check though.
I think theoretically Subversion could work its way up: first it could
note that d1/f1 is removed in both local tree and the repository. Since
it is the same change, it could then resolve that conflict. Then, seeing
no other changes in d1 in the local tree - it could conclude that the
deletion of the d1 directory is again the same operation - and resolve
that conflict, too. Lather, rinse, repeat for any higher-level directories.
Regards,
Alexey.
