Some of the git-svn tests can fail on fast machines due to a race in
Subversion: if a file is modified in the same second it was checked out
(or in for that matter), Subversion will not consider it modified.
Apparently there is also a "racy Subversion" problem parallel to the
"racy-git" problem. The machine is an Athlon 64 X2 3800+.

For example, test #3 of t9106-git-svn-commit-diff-clobber.sh will fail
if Subversion happens to fail to make any commit in test #2 of the same
file. Test #2 will silently pass if no commit was made, as it is not an
error to commit nothing. The commit in #3 is supposed to conflict with
the one from #2, but obviously won't if that commit wasn't made. So in
this case test #3's commit succeeds when failure is expected, and the
test fails. The [annotated] output of a test run where this happens is
attached. A couple of other tests have the same problem.

This may be a known issue, but my search of the archives was fruitless
and it doesn't appear to be documented anywhere. It's obviously one that
would need to ultimately be fixed in Subversion, although a workaround
in the test suite might help those whose builds depend on a passing test
suite. It's problematic for me to have the git test suite fail because
the git package for Debian runs the test suite while building, and will
abort the build if there are failures.

Until this race is fixed in Subversion I guess I'm stuck either skipping
the git-svn tests or inserting `sleep 1` in a few places to work around
it. A patch that works around this problem in all of the tests that
failed for me is attached in case its useful to someone. Even faster
machines may reveal more instances of the problem. I did not attempt to
"fix" any tests that will still pass if commits are lost.

Cheers,
Michael Spang