I'm working on this now; see this thread on the dev list:
From: Philip Martin <philip@codematters.co.uk>
Subject: Re: nasty commit bug
To: Kevin Pilch-Bisson <kevin@pilch-bisson.net>
Cc: SVN Dev List <dev@subversion.tigris.org>
Date: 15 Jul 2002 18:06:09 +0100
Philip Martin <philip@codematters.co.uk> writes:
> I would have expected this to try to commit libsvn_wc/props.c and for
> the server to reject it. The working copy is still rev 2471 and yet
> rev 2485 exists on the server. Somehow it succeeds?!? It then
> segfaults in the post-commit processing because it failed to lock
> libsvn_wc, but ignored the error and then tried to use the missing
> lock.
>
> Looking at the tar file, props.c is at rev 2471, and the text-base is
> correct for that revision. So why didn't the server reject the
> commit?
ra_dav looks to be at fault.
1. Check out a working copy.
2. Modify a file.
3. Run the svn client under gdb.
4. Set a break point at svn_wc_process_committed.
5. Commit and when the breakpoint is reached kill the client.
6. Remove the lock manually or use cleanup (this is necessary because
since r2506 the client will no longer ignore the lock).
7. Run the commit again.
When using ra_local the second commit fails, with transaction out of
date. When using ra_dav the second commit succeeds :-(
--
Philip Martin
Blocker 