2009/6/11 Nick Woolley <nickwoolley@xxxxxxxxxxx>
>
> Mike Ralphson wrote:
> > Hi Nick, I'm seeing intermittent failures since your new test was
> > added to 'next' on AIX 5.3
> >
> > cvs commit: Up-to-date check failed for ` space'
> > cvs [commit aborted]: correct above errors first!
> > * FAIL 15: re-commit a removed filename which remains in CVS attic
> > * failed 1 among 15 test(s)
> >
> > Let me know if there's anything I can do to help debug it.
> >
>
> I don't know why the " space" file seems to be causing a problem - it shouldn't
> interfere with the test I added (and indeed doesn't for me).
>
> Perhaps you could apply the following patch to t/t9200-git-cvsexportcommit.sh,
> run it, and send the contents of t/debug.out? What I get is appended after the
> patch.
On a failed run, the error is on the commit adding attic_gremlin:
echo > attic_gremlin &&
git add attic_gremlin &&
git commit -m "Added attic_gremlin" &&
git cvsexportcommit -w "$CVSWORK" -c HEAD &&
(cd "$CVSWORK"; cvs -Q update -d) &&
test -f "$CVSWORK/attic_gremlin"
cvs commit: Up-to-date check failed for ` space'
cvs [commit aborted]: correct above errors first!
* FAIL 15: re-commit a removed filename which remains in CVS attic
debug.out contains the following:
# before adding file
cvs status: nothing known about attic_gremlin
===================================================================
File: no file attic_gremlin Status: Unknown
Working revision: No entry for attic_gremlin
Repository revision: No revision control file
===================================================================
File: space Status: Needs Patch
Working revision: 1.1 Thu Jul 2 12:50:17 2009
Repository revision: 1.2 /usr/local/src/gitbuild/t/trash
directory.t9200-git-cvsexportcommit/cvsroot/ space,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===
the " space" file in cvswork is:
-rw-rw---- 1 mike staff 6 2009-07-02
13:50:17.000000000 +0100 space
CVS/Entries for the file has
/ space/1.1/Thu Jul 2 12:50:17 2009//
> You might also try commenting out the following part of my test, so that it
> should trivially work, and see if there's still an error:
>
> # rm attic_gremlin &&
> # cvs -Q rm attic_gremlin &&
> # cvs -Q ci -m "removed attic_gremlin"
It all goes a bit fun if I do that...
RCS file: /usr/local/src/gitbuild/t/trash
directory.t9200-git-cvsexportcommit/cvsroot/attic_gremlin,v
done
Checking in attic_gremlin;
/usr/local/src/gitbuild/t/trash
directory.t9200-git-cvsexportcommit/cvsroot/attic_gremlin,v <--
attic_gremlin
initial revision: 1.1
done
[master 20999b1] Added attic_gremlin
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 attic_gremlin
\1 better written as $1 at
/usr/local/src/gitbuild/t/../git-cvsexportcommit line 303.
Checking if patch will apply
Huh? Status 'Up-to-date' reported for unexpected file 'attic_gremlin'
Use of uninitialized value in hash element at
/usr/local/src/gitbuild/t/../git-cvsexportcommit line 263.
Use of uninitialized value in hash element at
/usr/local/src/gitbuild/t/../git-cvsexportcommit line 263.
Applying
error: attic_gremlin: already exists in working directory
cannot patch at /usr/local/src/gitbuild/t/../git-cvsexportcommit line 323.
* FAIL 15: re-commit a removed filename which remains in CVS attic
2009/6/12 Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx>:
> CVS har a timestamp in CVS/Entries that has whole second resolution. In
> addition it's built-in method for trying to work around the problem by sleeping
> until the next second wraps around is flaky. cvsexportcommit already has
> one sleep for this. Maybe it's not enough.
>From the comment in cvsexportcommit:
# CVS version 1.11.x and 1.12.x sleeps the wrong way to ensure the timestamp
# used by CVS and the one set by subsequence file modifications are different.
# If they are not different CVS will not detect changes.
sleep(1);
I tried changing this to 2 seconds, but I still got a failure on the
7th run. Life's too short to try changing it to 3 seconds in case I'm
being bitten by this from the perldoc:
"On some older systems, it may sleep up to a full second less than
what you requested, depending on how it counts seconds. Most modern
systems always sleep the full amount."
And that's not taking into account sleeps being interrupted due to signals.
Would it be acceptable to simply reorder the tests so this previously
unreported error goes away again?
Mike
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html