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.
Received on 2014-10-15 19:33:42 CEST