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

weakness in locking UI

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-01-04 17:50:30 CET

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

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.)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 4 17:53:01 2006

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

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