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
first...)
bye,
Erik.
---------------------------------------------------------------------
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