[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: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2004-10-14 15:35:11 CEST

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

>
> If people are using version control, there must be a reason.

Oftentimes, they're using version control because they're being forced
to.

These people are often using a 100% locking environment, and that means
they shouldn't have to learn about merging procedures, conflict
resolution prodedures, or anything else that one typically learns in a
class on 'concurrent VC practices'.

Hijacking is a rare thing; but when it happens, we shouldn't suddenly
throw all these concurrent concepts at the user. The client scolds the
user for hijacking, warns that a newer version of the file is in a
backup file, and then allows the hijacked file to be locked and
committed.

---------------------------------------------------------------------
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:35:30 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.