Why is "local delete, incoming delete upon update" of a directory a conflict?

Question

This is more of a hypothetical question, but I've always wondered why this case is considered a conflict. If I've locally deleted a directory which has already been deleted from the repository, why wouldn't this just resolve as you'd expect? What corner case am I not thinking of which would make the conflict status necessary?

Answer 1

I started digging in to this, and I think it may come from the fact that SVN is not entirely sure whether the delete is a simple delete, or actually a move (a copy, and a delete). From the documentation, it states:

Because a move in Subversion is implemented as a copy operation followed by a delete operation, and these two operations cannot be easily related to one another during an update, all Subversion can warn you about is an incoming delete operation on a locally modified file. This delete operation may be part of a move, or it could be a genuine delete operation.

So it sounds like to be safe, SVN warns you instead that you should update. Of course, it could ignore the delete "conflict", and simply copy over the newly moved folder, but I think some metadata may perhaps be lost with that locally.

One potential fix is to revert your change locally and let the incoming update handle deletion.

Answer 2

A tree conflict appears when you ask SVN to enable a change (with merge, or update) on a target file or folder that cannot perform the change. In your case, you asked SVN to enable a deletion of a folder that does not exist in your local copy. Why is it necessary? It is more of a warning for you, and for me it was helpful when one guy tried to move a directory when the other tried to delete it in another branch. The tree conflict was just like you described, and it was real. The two guys had to resolve it by deciding what to do with that folder.