* Magnus Hagander <magnus@hagander.net> [100119 10:44]:
> > 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.
Well, when I was running my conversion, I took a "cheap" way, I just
rsynced twice (with a delay, I don't remember how long I decided was long
enough) and made sure the 2nd rsync didn't do anything, before I let
fromcvs at the copy of CVSROOT.
Sure, it's not perfect either, I based that on the hope that no "single
CVS commit" would have a period of $X of inactivity on the CVSROOT.
Of course, that could all be useless (for my PG conversion) if the PG
CVSROOT that was an unstable point-in-time copy of the real CVSROOT, but
I was rsyncing CVSROOT of other projects too, so I needed it for my own
conversions...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
