tisdag 24 juli 2007 skrev Simon 'corecode' Schubert: > 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? I reread my post here... My last sentence was a comment to the patch and not the sleep in CVS. -- robin - 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
