SteveKing wrote:
> While trying out the locking feature I gathered some more information.
> And a 'locked' overlay seems more and more something we shouldn't do:
>
> - the working copy only has the information if a file is locked by the
> working copy itself. No information about a file locked by someone else!
> - if the svn:needs-lock property is set, the file get's the readonly
> flag set, i.e. apps can't save such files anymore (as long as the
> working copy doesn't have the lock on such a file).
>
> The only thing what such an overlay could show is:
> - file is readonly
> But we don't really need an overlay for that - the explorer already has
> a built-in column provider to show the file attributes.
>
> So what do you guys think? Should we implement a 'locked' overlay at all?
My thought is that there are two different use-cases:
At "Jo's Super Pixel Works LLC." all the users are working on unmergable
binary media. Everything has svn:needs-lock and it is assumed you need
the lock before editing.
In this case something telling you that "You *need* to lock" is
redundant. All that's really needed is something to say "You *have* the
lock".
At "Software & Sun LLC." there's a lot of source code, but also some
unmergable binary files mixed in between that have svn:needs-lock.
In this case something telling you that "You *need* to lock" on those
files with svn:needs-lock could be useful, combined with something
saying "You *have* the lock" when you have it.
As I understand it, Steve is saying that when the read-only flag is set
it has the same function as a "You *need* the lock" overlay. If the
read-only flag is not set it can mean "You *have* the lock" (if the file
has svn:needs-lock). If the user turns on the "attribute" column (and
has their explorer settings set so each window uses the same settings),
and uses the Details view, then they can look in this column to see if
they have the lock or not. If the user doesn't check the read-only flag
they'll find out the first time they save (as long as their app honours
the Read-only flag). (I hope I've not misrepresented, Steve?)
I can see the elegance of using something that already exists, but think
it ultimately isn't so good to rely only on the read-only flag:
1. In Software&Sun's situation it means you can't tell if you have the
lock for a file, or the file simply doesn't need the lock, without
checking the file properties and looking for svn:needs-lock. User's can
easily forget to release the lock. Having a "You *have* the lock"
overlay would help.
2. To actually see the read-only status in Explorer requires quite a bit
of hoop-jumping and restricts how you can use Explorer. In e.g. an Open
dialog you'd probably have to scroll horizontally to see the attribute
column.
(This, I think, is the only real problem in the PixelWorks case: easily
knowing if you have the lock or not, which could also mean users forget
to release their lock.) Having a "You *have* the lock" overlay would help.
3. In Software&Sun's situation, if the user doesn't notice the read-only
flag they'll only find out the problem after they try to save, which
could be after they've done a good deal of work. (And it only is a
problem if when they try to obtain the lock they find out someone else
already has it.) Having a "You *need* a lock" overlay doesn't mean
they'll never forget to get a lock before they start to edit, but it
would help.
I realize there are restrictions on how many overlays can be in
existance. I also don't know if overlays can be "overlayed" (i.e.
multiple overlays per icon). If not then the existance of a lock
overlay means exluding modified/unmodified information, which IMO, is
even more important. If multiple overlays are possible then I think
using overlays is a better, more-consistent UI approach.
Thoughts?
Best regards,
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Apr 13 22:34:18 2005