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