[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: Sander Striker <striker_at_apache.org>
Date: 2004-10-14 16:03:15 CEST

> From: Ben Collins-Sussman [mailto:sussman@red-bean.com]
> Sent: Thursday, October 14, 2004 3:51 PM

> On Oct 14, 2004, at 9:41 AM, Mark Phippard wrote:
>> 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.

> I'm suggesting that the UI be something like this:
> $ svn update hijacked-file.c
> WARNING: you have changed this file without locking it, which is bad!
> WARNING: a newer version of the file has been saved in 'hijacked-file-backup.c'
> WARNING: please examine the newer file before committing your own changes!
> How is that "wushing away" the conflict? Isn't that enough information
> to make the user review the newer file?
> The alternative is:
> $ svn update hijacked-file.c
> C hijacked-file.c
> ### "huh? what does C mean?"

I think the "huh?" arises much earlier: it starts with firing up
a shell. Or, when they end up in vi when they commit ;)
[ # calls administrator: "How do I get out of this thing?!" ]

Seriously, the user group you are now standing up for is much more
likely to use a GUI than to use the cmdline client. I'd like to see
us try to keep the cmdline client consistent and would propose that
we generate a 'regular' conflict. GUIs can solve this issue in their
own way (the API should allow for detecting if a conflict was
generated because of a hijacked lock).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 16:03:24 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.