* Magnus Hagander <mag...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature