Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Magnus Hagander wrote:
>>
>>>>>> the Git repository is missing parts of two non-recent
>>>>>> commits.
>>
>>> We've seen this happen before.
>>
>> That seems like kind of a blasé attitude toward something upon
>> which some people rely.
>
> For the record, I am one of those people. I use it for *all* my
> postgresql development. And this is a serious pain.
It appears I took your comment the wrong way. Apologies.
>> When we (at Wisconsin State Courts) were using CVS and had
>> scripts to automatically merge changes from one branch to
>> another, we saw this sort of thing unless people were very
>> careful to grab a timestamp in the past for their ranges and use
>> it throughout the script. Perhaps the script is just not careful
>> enough? (Said in total ignorance of what the PostgreSQL process
>> here actually is....)
>
> That would be one way. However, AFAIK the tool we use (fromcvs)
> doesn't support this. If somebody were to extend the tool with
> that, it would be much appreciated. It's a Ruby tool though, so
> there's not a thing I can do about it myself... And it's basically
> undocumented.
>
> But yes, if we do that and set the timestamp far enough back in
> time, that should make it "reasonably safe". Given how long some
> operations can take ((C) year change, release tagging IIRC, stuff
> like that), this has to be a fairly large number, which means the
> git mirror will lack even further behind. But if that's what we
> have to pay to make it safe, I guess we should... The time would
> have to be long enough to cover any cvs commit including potential
> network slowness during it etc.
My Ruby skills are minimal, but we've got some Ruby gurus around
here -- maybe between my rough skills and a few impositions on the
others I could wrangle something. Is there any particular version I
should be looking at? The last official version I can find is
0.0.0.132 from May 3, 2009.
Although, if there's not some reasonably obvious fix (like
subtracting some fixed amount of time from a timestamp they're
already grabbing), perhaps we should just plan on limping along
until we can convert to git.
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."?
-Kevin