On Sat, Jul 13, 2002 at 09:47:07PM +0100, Philip Martin wrote:
> Hello
>
> I believe r2504 is incorrect, if we do not find the expected lock at
> the start of post-commit processing then there is a bug somewhere. In
> that circumstance it is wrong to do as r2504 does and try and acquire
> the lock. There is an unexpected condition, we should not continue
> and modify the working copy, that may do more harm then good. It may
> also hide other bugs.
Based on my interpretation of the API, I think it would be valid
for the lock not to be held at the beginning of
svn_wc_process_committed().
In fact, that is a requirement in the code as it stands right now.
No locks in subdirectories may be held when svn_wc_process_committed
starts or it will attempt to recursively lock. Only the top-level
directory *may* be locked. The current code is broken right now with
recursive copies.
Here's a quick reproduction recipe:
svnadmin create `pwd`/testrepos
svn co file://`pwd`/testrepos -d test
cd test
mkdir foo
touch foo/bar
mkdir foo/foo2
touch foo/foo2/spaz
svn add --recursive foo
svn commit
svn cp foo bar
echo "I am on the branch" > bar/foo2/spaz
svn commit
The second commit will fail with a wc-locked error. With the
patch to enter svn_wc_process_committed() with no locks held
(and r2504 in place), it does not fail.
I believe r2504 needs to stay until svn_wc_process_committed() can
handle the above case with the locks held. At that point, the
assumption that we can enter that function with the locks is correct
(and r2504 can be reverted). As I have been trying to point out,
that is currently a false assumption. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 14 00:17:19 2002