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, 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. 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.
>
> Without any lock identification on the client side, it becomes a manual
> process that requires the user to remember to check for locks, examine
> the list of files, and be sure the one that has her interest is not in
> the list.
How would this be any different (or better, from a user's perspective)
from just enforcing the svn:needs-lock property? Before the user edits
the file, they'll need to obtain the lock, and if someone else has it,
they'll be informed at that time.
---------------------------------------------------------------------
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:09:59 2007