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

Re: Finding Locks

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-09-17 15:53:39 CEST

On 9/17/07, Bicking, David (HHoldings, IT)
<David.Bicking@thehartford.com> wrote:
>
>
> > -----Original Message-----
> > From: Larry Martell [mailto:larry.martell@gmail.com]
> > Sent: Friday, September 14, 2007 5:57 PM
> > On 9/14/07, listman <listman@burble.net> wrote:
> > >
> > >
> > > On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
> > >
> > > >>> I suspect that this is because the workspaces that do
> > _not_ have
> > > >>> the lock have no indication from the repository that
> > locks exist.
> > > >>> Is this
> > > >> a
> > > >>> correct guess?
> > > >>
> > > >> Yep.
> > > >>
> > > >>> It would be nice for
> > > >>> the workspace to know which files have locks on them (upon
> > > >>> "update",
> > > >> of
> > > >>> course), and better yet, to know who has those locks.
> > > >>
> > > >> I agree, this would be quite useful. Locking has always seemed
> > > >> like such an afterthought and really doesn't get a lot
> > of attention.
> > > >
> > > > I can't help it, but this is by design, not because locking is or
> > > > was an afterthought: it would be really useless to have this
> > > > information in a working copy, because the minute it's stored in
> > > > the working copy, that information may be outdated.
> > > >
> > > > If you want to have up-to-date information on locks, you need to
> > > > contact the server. That's what this 'non-availability' of
> > > > information is about...
> > >
> > > what command should we be using to get the list of locks from the
> > > server?
> >
> > svnadmin lslocks
> >
>
> I have to disagree with the assertion that it would be useless in the
> working copy. True, it could become invalid between updates,

Well, I'd not use the word /could/, I'd say *will*, because there's no
saying how long either the lock owner will keep the lock or how often
the user will update the working copy.

> but at
> least the user has some idea that a file she wants to use is locked by
> someone else as of the last update.

If you want to update the file, obviously, you'd need to acquire the
lock first. At that time, the client needs to contact the server to
acquire it. If a lock is already held, the user will be notified of
that fact...

> Then, a quick update will verify if
> that is still the case, and if it is the same person. Armed with this
> information, she can then contact that person and coordinate their work.

... and with that information she can go through the steps you describe above.

> Without any lock identification on the client side, it becomes a manual
> process that requires the user to remember to check for locks,

Not really, but it would require the user to lock the file, which,
obviously you want the user to do anyway...

> examine
> the list of files, and be sure the one that has her interest is not in
> the list.

> Can you see the value in this? Is there a chance you might change your
> mind?

Not yet, sorry.

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 17 16:10:22 2007

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

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