Re: Git out of sync vs. CVS

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