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

RE: RE: Re: Get exclusive lock

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: Tue, 4 Mar 2008 08:25:44 -0500


> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445_at_att.com]
> > -----Original Message-----
> > From: Bicking, David (HHoldings, IT)
> >
> > >
> > >
> The big debate in the 'communication of locks and changes'
> thread was that it was "pointless" to cache impromptu locks
> since the client is "always" out of date. (Impromptu locks
> are locks on files that do not have 'svn:needs-lock', and/or
> other people's locks.)
> In this case, 'svn:needs-lock' is there from the beginning
> (which is why the readonly flag is set,) and that this is
> more of a reminder/warning that one of your Applications
> changed your readonly file without your knowledge. More
> importantly, 'svn:needs-lock' is already being cached by the
> workspace, so all the lock information is already present.
> All the information needed to determine if you should be
> touching that file already exists, even when you're offline.
> The difference is that it's telling you that you _definitely_
> need to connect to the server and lock the file, whereas the
> other thread was about caching inherently out of date
> information about other people's locks.
> A gui client could implement this on their own as a courtesy
> feature without worrying about breaking standards (kind of
> like how Version Trees are not standard.) For the command
> line folks, it would be more convenient (and thus more like
> to be used) if 'svn status' would flag any modified, no local
> lock, 'svn:needs-lock' file.

That makes a whole lot of sense. Perhaps something can be implemented

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-04 14:26:13 CET

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.