Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "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.
I was trying to be accommodating; if Magnus's take on this isn't a
consensus, I'll put forward in a little more detail what I had in
mind.
What we did with our scripts was to grab the current time *from the
CVS server* (since not all clocks are necessarily set accurately)
and using that as the end of a time range. The end of the previous
time range was recorded on successful completion; we would us that
as the start of a time range. Done carefully, that allows no
commits to be missed. The only way something could be done twice
would be for the process to die after it had pushed through some
changes and before it reached completion and saved the time.
Now, I haven't looked at the fromcvs code yet to know how easy or
hard it would be to use this logic within that package, so this is
still pretty hand-wavy.
-Kevin