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

Re: Locking

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-11-13 22:01:59 CET

On Nov 13, 2007 8:47 PM, Moore, Tom <Tom.Moore@aig.com> wrote:
> I think you may have missed my point. Let me try to restate.
> You are right on the attribute svn:needs-lock scenario. It will always
> be read only unless a lock is set. So lets forget that scenario.. I went
> off on a tangent while trying to present the case.
> The point is that lock data is available in Subversion.

Right, but not to the Subversion client, since you need to contact the
server anyway to get acurate information.

> It is not
> explicitly made visible to the user at points where it would be useful
> (on update, checkout, etc.)

Right, because at that point of time it's not available to the
Subversion *client*.

> Instead the user is forced to jump through
> additional hoops when they shouldn't have to.

Yes they should. The word 'accurate' is key here: there's no way the
client can give the user accurate information. The server however can,
meaning that - for accurate info - you'll always need to contact the

> Or in the case of the
> commit failure message, its not a clear message. I can't tell you how
> many users in the past have come to me saying "I got an error" and they
> never even read the whole message.

Though we do have issues with error messages being unclear, not
reading them is not really our issue, is it? :-)

> >But the instant that update is complete, any lock data can be out of
> >date. One should always check w/ the server (svn st -u) to learn the
> >current lock situation for a file, not rely upon local WC info.
> The converse to this is true as well. The moment the svn st -u is done,
> any lock data can be out of date.

Right. Locking isn't a replacement for communications within the team.
It's there to help you prevent your users shoot themselves in the
foot. Chances of 'svn st -u' being incorrect right after you get the
output are far smaller however than 'svn st' would be (ie without
contacting the server).

> 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).

Nope. It does not and will not. That's by design. The only way to get
an *accurate* overview is by contacting the server...

> 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.

So will having svn:needs-lock, because then the users can't modify the
file without getting a lock on it first...

> 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.

Right, but that data would give the user an incorrect view of the
situation, because it might suggest to said user that if the working
copy *doesn't* show a lock, the file will probably be unlocked: this
isn't correct.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 13 22:02:35 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.