[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] how should the UI look like

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-04-08 21:31:21 CEST

J. Richard Mills wrote:
> Another vote, FWIW:
> I think I'm with #3. This comes from the "MS Word" perspective
> (primarily because it's those kind of users who will be using locks a
> lot), as well as a user of TortoiseCVS:
> 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?"

That's not really going to work. You can lock multiple files at once.
And maybe only one of them is already locked, but maybe 2 or even more
of them. So for each failed lock, we would have to show that dialog.
That's not good UI design - such a dialog always interrupts a user from
whatever (s)he's doing.

So you see why I'm asking for suggestions on the list - I've already
considered many options, but I'm just not really comfortable with either
of them.

> 3) Try to steal the lock, if *that* fails (i.e. due to permissions,
> server config, whatever), then throw the error back.

That's of course what we would do.

> I'm assuming that the server will take care of notifying the previous
> locker that her lock has been stolen and who stole it.

You would have to implement that in a lock-hook.

> Alternate option 2.1 might be "Request notification when lock becomes
> available." All of this, BTW, is exactly the way the MS Office products

That's not really possible from a client. That would have to be
implemented on the server.

> On a separate note:
> 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).
> Especially since the commands actually do the *opposite* of what they
> claim from the user perspective. The "lock" actually changes it from
> read-only (i.e. locked) to read-write (i.e. unlocked) so that you can
> edit the file. Perhaps "reserve" and "unreserve" or "edit and "unedit"
> as a UI-label make more sense (?). I got used to "cvs edit" from

both '(un)reserve' and '(un)edit' don't really look good. Sure, you're
used to the 'edit' from CVS, but I never liked that wording at all.
With 'reserve' it even worse - most people won't know what that means.

Maybe 'get lock' and 'release lock' might be more clear?


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Apr 8 21:31:49 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.