[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Update problem: Tree conflicts vs content conflicts

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-09-08 00:28:14 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> 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?

No, but I'm quite prepared to believe that other people want a more
conservative system :)

> You're deleting a file which
> contains changes you've never even looked at.

- I probably didn't examine the previous version of the file in any
  great detail before running 'svn rm'

- I run 'svn diff' before 'svn ci'

> 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.

The file will become unversioned only if user A has made further
changes after the commit, without changes the file will simply be
removed. I do expect users to know roughly what changes they have in
a working copy.

> I've seen users complain about both situations, especially the latter
> one.

There you've got me, I've never had to deal with such complaints from
users.

> 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?"

For the same reason I planned to delete the unenhanced file.

> or "hey, why didn't my edited file get into the repository?") Issue

Run "svn log". (I've never had to deal with a user who would ask such
stupid questions.)

> 2282 is about making noise in these situations, rather than doing
> silent conflict resolution.

I feel you are trying to be too novice-friendly at the expense of more
convenient behaviour for experienced users.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 8 00:29:05 2005

This is an archived mail posted to the Subversion Dev mailing list.