On Wed, Jan 09, 2013 at 02:02:32PM +0100, Roman Kellner wrote: > - Now the user-A needs to branch his WC and gets the following error > message on commit > (the file shown in the error message is the one that was created and later > deleted):
Please do not attach images when posting to a mailing list. Instead, copy/paste the error message into your email in plain text. > I would consider this a bug. Why does the client not simply ignore deleted > marked file entries? Subversion represents renames as a copy and a delete operation. Subversion does not allow you to commit deletions of outdated items, because this would prevent some tree conflicts from being detected. Please forget your particular problem case for a minute, and consider this instead: User 1: svn mv A B User 2: svn mv A C User 1: svn commit User 2: svn commit The second commit must fail so that User 2 is forced to update the working copy. This will cause a tree conflict to be flagged, to force User 2 to think about what to do about the conflict (A cannot be renamed to two different names -- User 1 and User 2 must agree on a new name or the rename should be undone). Subversion 1.5 would allow this commit, but as of Subversion 1.6 this was changed to avoid a gap in tree conflict detection. Also, it was possible to create empty revisions by committing the deletion of something that was already deleted. This is no longer possible as of 1.6. Does that make sense? Now, you might be wondering why I'm talking about renames rather than the deletion of an item, and how this still relates to your particular problem case. This is because Subversion generally cannot yet tell the difference between the following cases during conflict detection: svn mv A B and: svn copy A B svn rm A and: svn rm A Which is going to be addressed in future releases (1.8 and beyond). I hope the behaviour of future releases will be less and less confusing as we make further progress on this problem. The current behaviour can be confusing, unfortunately :-/
