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?
-
6Because subversion is an idiotic version control system. – Nick Hristov Aug 22 '13 at 18:47
2 Answers
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.

- 33,276
- 14
- 79
- 112
-
-
3@homemade-jam "Easiest" way is just to revert your change and let the incoming one delete that same directory. – Igor Aug 14 '13 at 21:24
-
2ok fine. imho the svn support for moving files around is atrocious. – homemade-jam Aug 15 '13 at 10:20
-
4For future readers: I had the conflict arise on a file that a coworker moved and i later deleted from the old position. So i had this despite the file being neither in my working copy nor in the repo at that position. Nevertheless, Sneakys suggestion of just `svn revert` the file and then update still solved it despite neither operation making any visible change to working copy or repo. – DeVadder Apr 08 '14 at 09:53
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.

- 51
- 4