Re: branching WC folder fails with files marked as deleted

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 :-/
Received on 2013-01-09 14:21:44 CET