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

Re: Locking consensus(es) so far

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-14 15:41:36 CEST

Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/14/2004 09:35:11
AM:

> On Oct 13, 2004, at 9:17 PM, Mark Phippard wrote:
> >
> > As for Scenario B, I just do not understand why you would not generate

> > a
> > conflict, when there is one. How are we helping anyone by not
bringing
> > this to the user's attention?
>
> Because we're trying to keep version control *simple* for non-techies,
> by avoiding the usual conflict procedure in the case of a hijacked
> file. This is all explained in section I of the locking-ui.txt
> document. I can't tell if you've read that section or not. If you
> disagree with this incentive, then we have much to discuss. :-)

I read both documents the day you posted them. I agree with the goal, but
I disagree with the current approach. There is a "greater good" here. You
cannot sacrifice the core concepts just because a user does not understand
them. That thinking is no different than Microsoft not making their OS
secure by default because "mom" couldn't figure things out. Look where
that has got us. Apple, and some Linux distros like Ubuntu, have shown
you can do this reasonably. And I am not a MS basher, or trying to do
that here ...

I just think that we cannot just wush away the conflict. The user needs
to know that they have created a conflict and they should review the files
before committing there change.

Just thinking out loud, if I were writing a GUI, I might allow a user to
commit a file that was in conflict, and just warn them that they might be
losing changes there were made in the file. If they say OK, I would
resovle the conflict and let them commit.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 15:42:04 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.