> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking_at_thehartford.com]
> Sent: Monday, March 03, 2008 2:10 PM
> To: Reedick, Andrew; users_at_subversion.tigris.org
> Subject: RE: RE: Re: Get exclusive lock
>
>
>
> >
> >
> > Persionally, multi-tasking, windowed OS clients like
> > TortoiseSVN should have an option to periodically check for
> > 'needs-lock' files that have been modified without a lock.
>
> Yeah, so do I, but that's very similar to "communication of locks and
> changes" (because the fact that the file needs a lock has to be stored
> locally - though I suppose you could get that from the file
> properties),
> which was a long debate a few months back about "regular" locks.
> Client
> software teams such as Tortoise aren't interested in creating their
own
> proprietary caching and communication mechanisms - they'd rather have
> the core software handle that. Caching lock status locally or
> regularly
> pinging the server for lock status is, according to the Subversion
> team,
> "right out". I feel that having client software automatically
querying
> the server is a bad idea, anyway, because it increases network traffic
> and demand on the server.
I remember that thread. However... this is Different(tm). We never
talk to the server.
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.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
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-03 21:10:18 CET