Sander Striker wrote:
>>From: Ben Collins-Sussman [mailto:sussman@red-bean.com]
>>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!
One problem with a warning is that it can easily whizz past in screens
full of update messages, and be unnoticed or forgotten.
>>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).
I agree. If someone has deliberately circumvented the lock
communication mechanism then it is reasonable for them to expect to have
to take some more (initially unfamiliar) action when they come to commit
the file. If they got into the situation accidentally, not knowing that
the tools they used circumvented the read-only protection, then it is
well and good that they should have to pause at this stage and read up
or ask for help.
Seeing some extra files appear and having to run "svn resolved" is not
such a frightening thing for even a non-techie user to digest if they
have already been using the command-line "svn update" and "svn commit"
etc. In my experience, non-techies learn to take a patient approach to
using computer software. When anything unfamiliar occurs they are
usually happy to seek help, whether on-line or off-line. If instead
they try to blunder on, at least this way they have to take a conscious
action rather than just seeing a warning and thinking, "Oh, well, there
was some sort of warning but nevertheless the operation seems to have
worked so I'll just carry on."
What Mark said about trying to improve the helpfulness of our conflict
error messages is also sane and pertinent. After "svn: err:
'hijacked-file.c' remains in conflict" add something like "Resolve the
conflicts and then use 'svn resolved'."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 17:13:27 2004