* Tom Lane <tgl@sss.pgh.pa.us> [100119 11:47]:
> "Kevin Grittner" <Kevin.Grittner@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
changedfor 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,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
