Toby Johnson wrote:
> J. Richard Mills wrote:
>>1) Attempt the lock
>>2) If it fails, throw up a box "Locked by So-and-so on mm/dd/yyyy hh:mm.
>>Do you want to steal the lock?"
>>3) Try to steal the lock, if *that* fails (i.e. due to permissions,
>>server config, whatever), then throw the error back.
>
> Instead of popping up a dialog for every failed lock attempt, perhaps if
> any locks fail it could pop up one dialog, with a list of all items
> which failed obtaining the lock. Each of these items would have a
> checkbox, un-selected by default, along with the existing lock-token or
> user or whatever the server returns.
>
> The message could say "These items are already locked in another working
> copy. You can attempt to 'steal' one or more locks from the existing
> user if necessary, but you should do this only if the other user is
> unavailable to release the lock themselves".
[further explanation snipped.]
Sounds like a good way to do it. But it seems overly complex.
For starters, I think we should just do what so many other
applications have done before: Steve's suggestion #3, with a slight
tweak:
- There should be "Steal All" and "Skip All" buttons.
- There should be a "Cancel" button.
This way, the user does not have to click h(is/er) way through a
hundred dialogs, (s)he can just decide that (s)he'd like to steal
every lock (if allowed), or alternatively not steal any of the locks
held by others or cancel the entire operation and wait till another
time.
I'm not sure if the Cancel should attempt to cancel the entire
transaction, including the locks already taken. Seems like a somewhat
complex (racy!) thing to do; with little actual benefit, so at first,
no.
Although this solution is simple to implement and thus will get
locking into TSVN and out to users faster ;-), there's a slight edge
case with it: the "Skip All" option. If TSVN is told to auto-skip
half of a bunch of files, how does a user know which files was
actually locked? It warrants for new lock overlay icons, or a status
dialog at the end of the operation. Not sure if this is important.
>>Also from the UI perspective: "lock" and "unlock" might not make
>>intuitive sense to your general purpose dummy user (Audience #2 from
>>http://svn.collab.net/repos/svn/trunk/notes/locking/locking-ui.txt).
Agreed. At the least, the "unlock" command should be named "release"
and grouped with "lock" in the context menu by separators, so that
users can deduct the idea of the commands simply by looking at them.
'Lock & release' does that nicely, I think. We could even phrase it
"Lock exclusively" or something like that.
> For better or worse, those are the terms agreed upon by the Subversion
> devs, so I doubt TSVN would want to invent its own conventions.
On the contrary. It's a technical term for what the Subversion
backend actually does; we should use terms that relate to what the
users are trying to do with that technical feature. I don't see any
problem with using a different wording. Other versioning systems
actually prohibits the user from changing local files if they have not
"acquired it for writing", eg. locked it, this is not the case for
Subversion. We definitely should be careful with the wording, and we
SHOULD use different terms than lock/unlock.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 17:50:31 2005