[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:57:12 CET

rooneg@gmail.com wrote on 01/04/2006 01:47:47 PM:

> On 1/4/06, Mark Phippard <markp@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
> > with as a result of trying to solve some other problem, such as
> > 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.


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 20:00:37 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.