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

Re: Enforcing the lock of a file prior to its commit.

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-07-21 16:47:57 CEST

On 7/21/06, Johan Appelgren <johan.appelgren@gmail.com> wrote:
> On 7/21/06, Luca Cappa <luca.cappa@sequoia.it> wrote:
> > On Thu, 20 Jul 2006 15:31:57 +0200, Johan Appelgren
> > <johan.appelgren@gmail.com> wrote:
> > >
> > > Have you looked at writing a pre-commit hook that does what you want?
> > >
> > > That wouldn't stop anyone from editing a file, then get the lock and
> > > then commit though. So I'm not sure what you'd gain?
> >
> > I would gain that the person needs to get the lock. If the lock is already
> > being held
> > by someone else, this guy is warned that the next time he removes the
> > read-only flag
> > (and changes it and then fails to lock it) he will remember to check if
> > there is
> > already any lock on that file prior to apply any modification to it.

This will gain you exactly as much as without locking: you won't be
able to commit to a resource which is older than the repository HEAD
version anyway. Committing a file (locally modified) which is at
revision 3 locally and at rev 5 in the repository, will result in a
'resource out of date' error. So, what do you gain by generating an
almost exact error like that your way? (Updating before the commit
works, but won't incorporate the changes in the repository in the
local file; the developer will need to remove the 'C'onflict state



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 21 16:49:22 2006

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.