You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2006/01/04 16:50:30 UTC
weakness in locking UI
So I have an interesting experiment going on: a group of
not-very-technical OS X users is using subversion to collaborate on a
large collection of binary files. (Musical scores, to be precise.)
They're using a combination of the svn commandline client and the Mac
Finder plugin "scplugin", which simply wraps the commandline client.
Because the files are binary, they're all marked with
'svn:needs-lock', and the users are all locking files before editing,
then allowing 'svn commit' to unlock them. Just as we designed.
But the complaint I keep hearing is that it's not easy to get a quick
overview of "who has which files locked". It's hampering their
communication. The current UI choices are pretty lame:
1. 'svn st -u' shows remote locks, but not owners. Users have to run
an incredibly awkward 'svn info URL' command on each file to see
who locked it.
2. 'svn ls -v directory' shows remote locks and their owners too, but
only within the immediate directory. And it's full of noise;
users don't want to see all files, just the locked ones. Adding
'-R' makes the noise even worse.
I think this is a big usability weakness in our UI. We need something
better.
The irony is that we *already* have a single RA command to "fetch all
locks below a repository path". We even have an example program
(tools/examples/getlocks_test.c) which demonstrates it.
For now, I think I'm going to build the getlocks_test binary on OS X
and just give it to this team to use as a workaround. But I'd love to
hear ideas about how to make the commandline client itself more
usable. (For GUI tools like TSVN, I imagine some sort of "locks
report" would be a nice thing to add.)
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/4/06, steveking <st...@gmx.ch> wrote:
> In TSVN, you can use the "check for modifications" dialog, then sort by
> the 'locks' column to get all locks and owners in the whole working
> copy. Not sure if a separate 'locks report' would help that much.
Well, in some sense, that's still a "locks report", it's just part of
a larger report. Much like the way 'svn st -u' shows locks. I'm glad
TSVN has this.
>
> What many users often request on the TSVN list is an overlay for locked
> files, as well as a separate column for who locked the file. But that
> could only be done if that information is cached in the working copy
> itself (I can't keep a connection open to the repository from the
> explorer, that would make the whole system so slow it would be unusable).
> The problem I see with that approach is that this information would only
> be updated on e.g. commits/updates/st -u/...
Yeah, but then that sort of goes against our locking design. We want
users to be aware of "local" vs. "remote". Browsing the working copy
is different from browsing the repository... that's why TSVN has a
repository browser. In that same vein, if Explorer shows any locking
information at all, it should be showing *local lock tokens*, which is
a distinctly different thing than a remote repository lock. We want
users to understand the difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by steveking <st...@gmx.ch>.
Ben Collins-Sussman wrote:
> For now, I think I'm going to build the getlocks_test binary on OS X
> and just give it to this team to use as a workaround. But I'd love to
> hear ideas about how to make the commandline client itself more
> usable. (For GUI tools like TSVN, I imagine some sort of "locks
> report" would be a nice thing to add.)
In TSVN, you can use the "check for modifications" dialog, then sort by
the 'locks' column to get all locks and owners in the whole working
copy. Not sure if a separate 'locks report' would help that much.
What many users often request on the TSVN list is an overlay for locked
files, as well as a separate column for who locked the file. But that
could only be done if that information is cached in the working copy
itself (I can't keep a connection open to the repository from the
explorer, that would make the whole system so slow it would be unusable).
The problem I see with that approach is that this information would only
be updated on e.g. commits/updates/st -u/...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Mark Phippard <ma...@softlanding.com>.
rooneg@gmail.com wrote on 01/04/2006 01:47:47 PM:
> On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
>
> > Is there any specific reason they want this? It just doesn't sound
like a
> > real requirement, it sounds more like the sort of idea you would come
up
> > with as a result of trying to solve some other problem, such as
showing
> > the lock info locally in decorators.
>
> It sounds to me like they're using locks as an indicator of who's
> currently working on a file, and they want to list who's holding locks
> as a way to see who's doing what. Seems like a reasonable use case to
> me.
One other thing that hasn't been mentioned yet and that is the hooks.
Weren't the hooks designed and intended to let you plugin in mailer.py to
send lock notifications? That doesn't really solve the problem but I
thought I would remind sussman of that feature since he did not mention
it.
It sounds like a web page that runs and displays svnadmin lslocks might be
the right answer.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/4/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
>
> > Is there any specific reason they want this? It just doesn't sound like a
> > real requirement, it sounds more like the sort of idea you would come up
> > with as a result of trying to solve some other problem, such as showing
> > the lock info locally in decorators.
>
> It sounds to me like they're using locks as an indicator of who's
> currently working on a file, and they want to list who's holding locks
> as a way to see who's doing what. Seems like a reasonable use case to
> me.
That's exactly their use case. "Who is working on what right now?"
It doesn't seem unreasonable to me, especially when the entire project
is all binary files. It's just a communication tool.
This same team used to use a spreadsheet to accomplish the same
effect. The manager managed the spreadsheet and would email specific
files to specific team members to work on. When finished, the team
members mailed them back to the manager. The manager would then
redistribute the newest files to everyone else. In other words, the
manager was playing the role of the svn repository. People repeatedly
got used to asking the manager "who was working on what?", and only he
could answer that question. They're very excited at the idea of
subversion being able to answer that question for them.
Yeah, I guess 'svn ls -R -v dir | grep " O "' might work, but it's not
particularly friendly. What we really fits the bill is 'svnadmin
lslocks', which is the same as what RA->get_locks() returns.
Maybe it's not something that belongs in svn proper, but in some
side-tool. Dunno. Or maybe it just belongs in a GUI tool, like
scplugin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Mark Phippard <ma...@softlanding.com>.
rooneg@gmail.com wrote on 01/04/2006 01:47:47 PM:
> On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
>
> > Is there any specific reason they want this? It just doesn't sound
like a
> > real requirement, it sounds more like the sort of idea you would come
up
> > with as a result of trying to solve some other problem, such as
showing
> > the lock info locally in decorators.
>
> It sounds to me like they're using locks as an indicator of who's
> currently working on a file, and they want to list who's holding locks
> as a way to see who's doing what. Seems like a reasonable use case to
> me.
I am not saying that one could not come up with an explanation as to why
someone might want this feature, but most of the reasons tend to be more
"managerial" in nature and get into a questionable area as to whether they
are really applicable to a version control solution.
I have never run svnadmin lslocks, but could someone not write a small PHP
script to run it, format it, and display it in a web page? If the svn
command line exists for a programmer, is this function something that a
programmer needs?
I still think what most people want is what I and Stefan King brought up.
They want this information cached in the WC so that it can be used by
GUI's to dynamically indicate the status of the file. Usually when you
explain why this does not make sense, most people accept it. I tend to
think that this request is what you come up with after the previous one
has been rejected.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
> Is there any specific reason they want this? It just doesn't sound like a
> real requirement, it sounds more like the sort of idea you would come up
> with as a result of trying to solve some other problem, such as showing
> the lock info locally in decorators.
It sounds to me like they're using locks as an indicator of who's
currently working on a file, and they want to list who's holding locks
as a way to see who's doing what. Seems like a reasonable use case to
me.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Maybe it's as simple as 'svn st -u' getting a lock-owner field.
I think that is a very reasonable solution:
1) we already have to do a roundtrip to the server (so no performance
penalty);
2) 'st -u' is already established to be a point in time (so no worrying
about race issues with commits in progress);
3) it should be relatively clean to add (though it will change the CLI
output).
+1
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Mark Phippard <ma...@softlanding.com>.
sussman@gmail.com wrote on 01/04/2006 12:16:43 PM:
> On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
>
> > I have mixed feelings. When you try to lock a file, it will fail and
tell
> > you who has it locked. Why did I really need to see this info before
> > attempting to lock the file? What difference would it have made?
>
> I think we're talking about different problems here. My users aren't
> so worried about seeing the latest repository-lock information as they
> casually browse through Finder or Explorer, but they *would* like an
> easy-to-run command that gives a 'locks report': "here are all the
> current locks, and all their details".
Is there any specific reason they want this? It just doesn't sound like a
real requirement, it sounds more like the sort of idea you would come up
with as a result of trying to solve some other problem, such as showing
the lock info locally in decorators.
svnadmin lslocks shows this information doesn't it? Obviously not
remotely.
> This would certainly fix the annoying "have to type the whole URL"
> problem that 'svn info URL' presents. But I still think we need the
> ability to fetch a locks-report somehow. Maybe it's as simple as 'svn
> st -u' getting a lock-owner field.
How about a new switch to svn ls, such as svn ls --locks-only. This could
optionally be combined with the --recursive option. This would work like
svn ls, except only show items with active locks. This would help
eliminate the noise and save from adding a new sub-command.
As with svn ls, this could work either locally or against a remote
repository.
Personally, I would prefer svn lslocks as it would give the opportunity to
bring back all of the lock information including the comment.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Michael Pilato <cm...@collab.net>.
On Wed, 2006-01-04 at 11:16 -0600, Ben Collins-Sussman wrote:
> This would certainly fix the annoying "have to type the whole URL"
> problem that 'svn info URL' presents. But I still think we need the
> ability to fetch a locks-report somehow. Maybe it's as simple as 'svn
> st -u' getting a lock-owner field.
As I mentioned in IRC, I don't like the idea of 'svn st' getting a lock-
owner field because in the -v case, that would further push the path off
the right side of a typical 80-column display (the paths already start
in something like column 40). There are only so many piece of
information you throw at someone before the noise level is just too
high.
I'd propose a simple 'lslock [-u]' subcommand, but there are those among
us who are frightened by growing the size of the command set (as if
folks have trouble wielding a Unix shell because of all those crazy
little commands you have to remember...).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: weakness in locking UI
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2006-01-04 at 11:16 -0600, Ben Collins-Sussman wrote:
> they *would* like an
> easy-to-run command that gives a 'locks report': "here are all the
> current locks, and all their details".
If you poll a thousand user sites, you will probably find two thousand
different reports users would like to be able to generate. I'm not sure
if Subversion should be trying to accomodate all of them.
Why do they want to know who has what locked? It doesn't sound like
they want to know for version control reasons; it sounds like they want
to know for managerial reasons. We provide a way to generate the raw
information needed for such a report, I believe ("svn ls -vR" and some
filtering, right?); that seems good enough.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/4/06, Mark Phippard <ma...@softlanding.com> wrote:
> I have mixed feelings. When you try to lock a file, it will fail and tell
> you who has it locked. Why did I really need to see this info before
> attempting to lock the file? What difference would it have made?
I think we're talking about different problems here. My users aren't
so worried about seeing the latest repository-lock information as they
casually browse through Finder or Explorer, but they *would* like an
easy-to-run command that gives a 'locks report': "here are all the
current locks, and all their details".
>
> What if svn info, when run on a local WC file, had an option to get the
> latest server information? This could then show you the current lock
> information from the repository, as well as if the file were out of date.
> GUI's could possibly use this as a way to provide an option users could
> use to check the information for a file before locking it.
>
This would certainly fix the annoying "have to type the whole URL"
problem that 'svn info URL' presents. But I still think we need the
ability to fetch a locks-report somehow. Maybe it's as simple as 'svn
st -u' getting a lock-owner field.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: weakness in locking UI
Posted by Mark Phippard <ma...@softlanding.com>.
sussman@gmail.com wrote on 01/04/2006 11:50:30 AM:
> I think this is a big usability weakness in our UI. We need something
> better.
>
> The irony is that we *already* have a single RA command to "fetch all
> locks below a repository path". We even have an example program
> (tools/examples/getlocks_test.c) which demonstrates it.
>
> For now, I think I'm going to build the getlocks_test binary on OS X
> and just give it to this team to use as a workaround. But I'd love to
> hear ideas about how to make the commandline client itself more
> usable. (For GUI tools like TSVN, I imagine some sort of "locks
> report" would be a nice thing to add.)
>
> Thoughts?
Users on the TSVN and Subclipse mailing lists have frequently requested
decorators to show that someone has a file locked. To do this, that
information has to be cached in the WC. This idea has always been
rejected by the devs based on the argument that it would almost alwys be
stale info. Given the choice, as well as possibly an option to refresh
the information, some of these users have said they would prefer it.
I have mixed feelings. When you try to lock a file, it will fail and tell
you who has it locked. Why did I really need to see this info before
attempting to lock the file? What difference would it have made?
What if svn info, when run on a local WC file, had an option to get the
latest server information? This could then show you the current lock
information from the repository, as well as if the file were out of date.
GUI's could possibly use this as a way to provide an option users could
use to check the information for a file before locking it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org