svnsync exits cleanly but leaves lock behind / svnsync raises inexplicable "MERGE request failed" error

I've been using svnsync for a while, to keep a replicated server
available in case the main one shuffles off unexpectedly to dead
hardware heaven.

There's a post-commit script which runs svnsync and emails me the
standard error output in the event of a non-zero exit status.
Occasionally I get an email telling me "svnsync: Couldn't get lock on
destination repos after 10 attempts" when the commit rate gets heavy,
but that's to be expected if a second user's commit completes while a
previous user's svnsync operation is still running.

Generally this works really well, but I have noticed two problems which
don't appear to be reported elsewhere (maybe svnsync isn't that widely
used yet?):

1) Occasionally the revision 0 property "svn:sync-lock" remains set on
the destination repository after svnsync has exited. I do not get any
email telling me something strange has happened, which suggests the
svnsync process had a zero exit status. It might just be something wrong
in my post-commit script of course, but I don't think it should be
possible to get a zero exit status out of svnsync unless the locks have
been properly cleaned up. Naturally, this stuffs up any subsequent
svnsyncs until I delete the lock.

2) I have twice had a very odd looking error back from svnsync; here's
the one I kept:
    svnsync: MERGE request failed on '/svn/imp'
    svnsync: Conflict at '/dev-mod/FWP/M2233/FWP_Engine'
'svn/imp' is the path to the repository; 'dev-mod/FWP/M2233/FWP_Engine'
is the path within the repository. I have checked out and compared trees
around this point from both the main server and the backup server, and
they are still identical, as they should be. I guess 'MERGE request' is
a WebDAV thing? I didn't get to check the results of these svnsyncs
until later svnsyncs had run, so it's possible the failure, whatever it
was, was corrected in a subsequent sync.

For completeness, the software involved is Windows 2003 on both servers,
with Subversion 1.4.3. The main server is running Apache 2.0.55 with the
standard Subversion distribution, and the standby is running Apache
2.2.4 with the Subversion modules from apachelounge. (I needed to do
this as I was getting difficulties with big revisions due to a bug in
the APR-0.9; I intend to move the main server over to this configuration
too).

I note that Subversion 1.4.4 fixes a server fault "race condition when
changing FSFS revprops (r23439, r23440)" - could this have anything to
do with it? If not, and if anyone can back me up on this, I will file a
bug report. It's not really a problem, since the repositories seem to be
staying in step correctly, but it would be nice to sort out.

regards,

--
Jon Ashley
This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 
Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support@praxis-his.com.
Praxis High Integrity Systems Ltd:
Company Number: 3302507, registered in England and Wales
Registered Address: 20 Manvers Street, Bath. BA1 1PX
VAT Registered in Great Britain: 682635707
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org