BUG? racy behavior in svn client version 1.3.2

Hello,

I have a wrapper script that manages a large change broken up into a
sequence of small commented diffs. When I commit the changes the
wrapper submits them all in a batch. Up until a couple of days ago it
worked just fine. I tried a sequence of 13 diffs when I first wrote the
feature and everything worked.

Now a batch with one change works, but if there are more than two
changes it fails. svn output looks extremely racy, and at this point
my working-copy meta-data is completely corrupt which the wrapper script
never directly touches.

My assumption is this: that when svn client process *I exec'd* returns
I can submit the next commit as fast as perl can turn around a glorified
patch + fork/exec().

Is that assumption valid ?

If you want the nitty gritty read beyond this point:

The setup is a client and repository on the same machine, one user. The repository
type is "fs".

what has changed between it working and not working ? unfortunately everything.
kernel, subversion install, wrapper script. I have tried reverting to the version of the
wrapper script that first worked, but at the point I tried it the working-copy meta-data
was completely trashed.

here two different kinds of failures logged by the wrapper. Note that:

< is my script reading the stdout from svn
> is commands exec'd
= is actions performed by the wrapper

--------SNIP---------

< /usr/bin/svn 2>>"race-log" status --verbose |
=patching rc with delta rc.deltas/improve-cset.000.diff
> /usr/bin/svn "commit" "rc" "--file" "rc.deltas/000.improve-cset.txt"
>interface status: 0
=unlinking delta pair rc.deltas/000.improve-cset.txt rc.deltas/improve-cset.000.diff
=patching rc with delta rc.deltas/log-cset.001.diff
> /usr/bin/svn "commit" "rc" "--file" "rc.deltas/001.log-cset.txt"
svn: Can't open file 'rc.deltas/000.improve-cset.txt': No such file or directory
>interface status: 256

--------SNIP---------

This is bizzare because clearly the svn client that committed
improve-cset.000.diff already terminated, before the svn interface
writes the message about the changelog missing, after the second commit
ran.

Here is another one but with even worse behavior.

--------SNIP---------

< /usr/bin/svn 2>>"race.log" status --verbose |
=patching rc with delta rc.deltas/repository-join.000.diff
> /usr/bin/svn "commit" "rc" "--file" "rc.deltas/000.repository-join.txt"
>interface status: 0
=unlinking delta pair rc.deltas/000.repository-join.txt rc.deltas/repository-join.000.diff
=patching rc with delta rc.deltas/rename-detect.001.diff
> /usr/bin/svn "commit" "rc" "--file" "rc.deltas/001.rename-detect.txt"
svn: Working copy '/usr/home/mattie/projects/rc' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
>interface status: 256

--------SNIP---------

after running this + "svn cleanup" svn thinks the commit actually went
through (svn -v status shows no modifications) but there are no new
entries in the log. I can't commit by hand with the svn client because
the working-copy meta-data is completely screwed.

svn cleanup is not reliable AFAICT.

I will strace the whole thing after I clean up the mess that was left, and I will check-out
a fresh working-copy.

I would have done that earlier but I wanted to test the failure behavior
of svn, to see what svn and my script could do in the nasty corner cases.

any insight into the guarantees provided by the svn client termination would be greatly
appreciated.

Cheers,
Mike Mattie