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

RE: Re: Atomicity of locks and needs-lock

From: Edward Harvey <eharvey_at_chilsemi.com>
Date: 2006-05-03 00:36:08 CEST

> Locks are a similar story - in addition to enforcing that the
> repository does not change out from under the user who locks
> a file, they are (or should be) an advisory mechanism (yes, I
> said "advisory") telling other users that they should be
> careful editing locked files, because of an increased chance
> of merge conflicts later, after the files are unlocked.
>
> You can't eliminate these kinds of race conditions with
> subversion's architecture, all you can do is train users to
> minimize the chance of problems by such habits as using 'svn
> update' frequently, as well as good old-fashioned team
> communication. But really, why _shouldn't_ the fact that a
> file is locked by a given user be communicated to other
> users, when the opportunity presents itself ('svn update')?
> Surely you don't think it is useless information just because
> it may become out of date? That's no big deal, everyone
> knows that the entire working copy can become out of date.
> The race condition is harmless anyway, the worst that can
> happen is some wasted effort.

I like the way you think, Peter.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 3 00:36:29 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.