* Tom Lane <t...@sss.pgh.pa.us> [100119 11:47]: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > > Oh, and what sort of delay do you feel would be "long enough to > > cover any cvs commit including potential network slowness during it > > etc."? > > Why should the script make any assumptions about delay at all? > It seems to me that the problem comes from failing to check for > changed files, no more and no less. It would be much less of an > issue if a non-atomic CVS commit showed up as two separate GIT > commits with similar log messages.
Well, I guess you could say: "fromcvs should go back and recheck all the previous work it's done, and double check and make sure no new files have changed for the timestamp/log message pair it's already done, because CVS isn't atomic" But, I think that path leads to craziness... I mean, how far back? CVS is "non-attomic" enough that 2 (well, $N) people can commit separate stuff, all with overlapping time stamps, and they can even commit stuff in the "past" of they really want... But, all I have to say is it's not perfect, pretty good, just deal with the things as they come, after all, it's "CVS" ;-) If you want better than "pretty good", drop CVS, do a one-time conversion (a la parsecvs/cvs2git) and get on with life... As long as CVS is the tool of choice, pretty good is really good... -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
