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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

sussmangmail.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 1/4/06, Mark Phippard <markpsoftlanding.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

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 <cmpilatocollab.net> 
CollabNet   <>   www.collab.net   <>  
Distributed Development On Demand

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.tigr
is.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

sussmangmail.com wrote on 01/04/2006 12:16:43 PM:

> On 1/4/06, Mark Phippard <markpsoftlanding.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 1/4/06, Mark Phippard <markpsoftlanding.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

rooneggmail.com wrote on 01/04/2006 01:47:47 PM:

> On 1/4/06, Mark Phippard <markpsoftlanding.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org