Robin Rosenberg 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.
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
This is a strange thing. CVS has this in their commit code since 1996. So I wonder why this is getting triggered.
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.
The question also is, why does this happen on two sequential invocations of cvsexportcommit, but not on two cvs commits done by cvsexportcommit? This should look the same to cvs, no?
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
-
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
