On Sep 7, 2005, at 2:39 PM, Philip Martin wrote:
>
> I don't think the "stomping" problem is real. If I schedule 'foo' at
> rX for deletion in my working copy, then I update to rX+Y and 'foo'
> updates I would be quite happy for it to remain scheduled for deletion
> and for my commit to delete the newer 'foo'.
Doesn't that seem reckless, though? You're deleting a file which
contains changes you've never even looked at. Isn't that a sort of
'stomping'? Of course, you have every right to do this -- but I
think we're being irresponsible by not flagging the situation as some
sort of conflict that needs attention.
There's a basic conflict of intent here: user A wants to enhance the
file's contents, user B wants to delete the file. At the moment,
we're not flagging this conflict in any scenario. If user A commits
first, user B inadvertently ends up deleting a file he's never seen.
If user B commits first, then user A's edited file becomes
unversioned... usually lost in the noise of the update.
I've seen users complain about both situations, especially the latter
one. The problem is that in both scenarios, the svn client is
resolving the conflict-of-intent in a silent, stealthy way. Users
don't even realize it's happening, and then end up confused and
annoyed later. (Either "hey, why did you delete my enhanced file?"
or "hey, why didn't my edited file get into the repository?") Issue
2282 is about making noise in these situations, rather than doing
silent conflict resolution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 7 23:57:57 2005