Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

måndag 23 juli 2007 skrev Simon 'corecode' Schubert:
> Junio C Hamano wrote:
> > It may be that we may want to fix this inside cvsexportcommit
> > itself, instead of working it around in the tests.  If somebody
> > tries to push more than one commit from git using two
> > cvsexportcommit in a row, he would need to make sure that the
> > second run happens one or more seconds after the first run,
> > otherwise he will see the exact corruption in real life.
> 
> Ah, now I see the problem.  The timestamp in the CVS/Entries is the same (because it only has second granularity), 
> so cvs commit won't consider it as changed. 
> 
> That's the reason why CVS usually waits until the second turns after a "update" (obviously not after a "commit"). 
> So we could either turn back the timestamp in the Entries file (ugly) or simply wait until the second turns.  Given 
> the overall cvs performance, this won't be a big issue, I guess. 
> 
> cheers
>   simon
> 

CVS sleeps after commit here. Can we bisect it? I have 1.12.3 (mandriva). The patch below I think
would work around the problem, rather than trying to fix the test. but I'd like to have the last CVS 
revision where it does not work for the patch comment 

Since the sleep is per invocation of cvsexportcommit it won't hurt too much since it is rarely invoked
on a huge number of git commits.

-- robin

diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d6ae99b..6377408 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -277,6 +277,10 @@ if ($opt_c) {
 # clean up
 unlink(".cvsexportcommit.diff");

+# timestamp problems. Invoking this command on a machine that is too fast may result in
+# CVS not recognizing changed because the timestamp is unchanged
+sleep(1);
+
 sub usage {
        print STDERR <<END;
 Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-m msgprefix] [ parent ] commit