I have found something that, in my view, is a bug. It's easily
reproducible with the script attached (it's a Korn Shell script but it'd
be easy to change it for Windows).
If the post-lock hooks fails, the user get the message "Lock succeeded,
but post-lock hook failed". It seems correct, especially because, AFAIK,
the exit code of the post- hook doesn't matter.
The file is indeed locked, but with a status of O instead of K. From the
Subversion book, O means that the files is locked by someone else
(wrong) or somewhere else (wrong). Although the file seems to be locked,
if it has the svn:needs-lock property set it's still read-only (but
maybe this is related to the fact that Subversion thinks that the file
is not locked in that WC).
I discovered the problem because my post-lock script did not have an
"exit 0" at the end and the return code was not zero (there was an error
with the set command). As you can see, my script simply creates a
post-hook with "exit 1" to make it failing.
Anyhow, I believe this is not the correct behaviour. As clearly state in
the message that Subversion returns, the lock has succeeded (as it
should since the post-lock return code shouldn't matter) but not in the
right way: you cannot commit, nor you can unlock the file. The only way
to remove the lock is to use svnadmin rmlocks.
I'm using Subversion 1.4.4
Am I missing something or is it really a bug?
Thanks
Giulio
P.S. In the wrong-lock script you need to change the path of the
repository when checking out the WC
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-23 16:01:39 CEST