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