All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: Michael Spang <mspang@uwaterloo.ca>
Cc: git@vger.kernel.org
Subject: Re: git-svn test suite failures due to Subversion race
Date: Mon, 12 Feb 2007 02:38:22 -0800	[thread overview]
Message-ID: <20070212103822.GA21413@localdomain> (raw)
In-Reply-To: <45CFDFDE.8080907@uwaterloo.ca>

Michael Spang <mspang@uwaterloo.ca> wrote:
> 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+.

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
issues.

> 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.

Not known to me.  This is the first time I've heard of this issue; but
I'm not at all surprised that this is happening, though.

> 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.

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::
libraries exclusively; but that runs the risk of introducing new bugs.

> From 97e90fcd7cf600726ec468016eb37d1e1de38dde Mon Sep 17 00:00:00 2001
> From: Michael Spang <mspang@uwaterloo.ca>
> Date: Sun, 11 Feb 2007 20:56:22 -0500
> Subject: [PATCH] Work around Subversion race in git-svn tests.
> 
> Signed-off-by: Michael Spang <mspang@uwaterloo.ca>

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

  reply	other threads:[~2007-02-12 10:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12  3:32 Michael Spang
2007-02-12 10:38 ` Eric Wong [this message]
2007-02-13  2:34   ` Michael Spang
2007-02-13  3:03     ` Junio C Hamano
2007-02-13  3:21     ` Eric Wong
2007-02-13  6:17       ` Junio C Hamano
2007-02-14  1:35       ` Michael Spang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070212103822.GA21413@localdomain \
    --to=normalperson@yhbt.net \
    --cc=git@vger.kernel.org \
    --cc=mspang@uwaterloo.ca \
    --subject='Re: git-svn test suite failures due to Subversion race' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.