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

RE: RE: Locking

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-11-14 14:36:20 CET


> -----Original Message-----
> From: Moore, Tom [mailto:Tom.Moore@aig.com]

> -u is done, any lock data can be out of date. The system
> should fail "safe" and if it detects a lock on update (or
> checkout) then it should note it and record that in the
> working copy (which would make it easier for clients like
> Tortoise to then display the lock). If the working copy
> indicates a lock, even though the lock has been released
> since the last update, that's the "safe" failure as it alerts
> the user to a potential problem before it occurs. The locked
> status in the working copy would tell the user to do one of
> the following:
> 1) Go talk to the person who has the file locked.
> 2) Wait and later try a svn update or status -u on the file
> to see if the lock has been released
> 3) Choose to break the lock.
> I'm not advocating putting more restrictions on the file
> modification process. I'm advocating enhancing the existing
> commands to provide data that is already captured in a manner
> that is easily understood by the end user.

I second this notion. Here are my previous threads concerning this

Simply knowing who (potentially plural) got a lock can be quite useful.
Making that available to Tortoise, Ankh or any other GUI client would be
good. It is a high visibility feature that shows polish. Obviously, I
know nothing about the underlying implmentation of the software, but it
seems like it _might_ not be a huge amount of work.

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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 14 14:37:03 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.