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