Re: Git out of sync vs. CVS

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