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
[ message continues ]

I don't think any of my machines are even half as fast.  The git-svn
tests take a long time on my dev machine, so we have entirely different

Not known to me.  This is the first time I've heard of this issue; but

This is disconcerting.  Given that hardware is still getting faster, I
suspect there will be many more problems with the svn tests in the
future.  I have no plans for upgrading hardware in the near future; so I
won't be hitting these problems myself.

I'm alright with adding the `sleep 1` in several more places where this
can be an issue.  If it gets bad enough for people with slower
computers, I'll probably just create a function that sleeps only if a
variable is not set (TOO_SLOW_TO_RACE=1 :)

I've been considering rewriting the tests to use the Perl SVN::

It would've been good to have the above email explanation above in the
commit message below so we know why the patch was needed (when it gets
applied).

-- 
Eric Wong
-

[ message continues ]

I've prepared a somewhat cleaner patch that solves the problem without
using sleep. It increases the modification time by one second
immediately prior to each commit. I added calls everywhere I think the
problem could potentially occur.

I've had no failures with the patch (without it, they are quite frequent).

Cheers,
Michael Spang
[ message continues ]

I've seen the failures myself without the patch, and working it

I wonder how portable this might be.

-

[ message continues ]

Thanks for the patch.  Just one portability nit below, otherwise:

I'm not sure that -d is portable.  However,

  perl -e '@x = stat($ARGV[0]); utime($x[8], $x[9] + 1, $ARGV[0])' "$1"

should work on any platform git-svn runs on.

-- 
Eric Wong
-

[ message continues ]

Sounds sensible, as git-svn wants perl-svn libraries already
anyway.


-

[ message continues ]

Doh. I knew that option to touch was too good to be true. Having it in
Perl may also make it easier for you if you decide to go ahead with
rewriting the tests to use only the Perl bindings. Assuming a workaround
is still needed, anyway--I've never used Subversion with Perl. Thanks
for the tips.

Michael Spang
[ message continues ]