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

Re: weakness in locking UI

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-01-04 19:16:58 CET

sussman@gmail.com wrote on 01/04/2006 12:16:43 PM:

> On 1/4/06, Mark Phippard <markp@softlanding.com> wrote:
> > I have mixed feelings. When you try to lock a file, it will fail and
> > 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

> 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

Personally, I would prefer svn lslocks as it would give the opportunity to
bring back all of the lock information including the comment.


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
Received on Wed Jan 4 19:30:02 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.