On Mar 27, 2008, at 10:47 AM, Aidan Van Dyk wrote:
> I was recently made aware of this:
> http://repo.or.cz/w/PostgreSQL.git?
> a=commit;h=69db64c737012a8d2d6fbcce3ace7136cb2bc85f
>
> I started digging around to figure this out on Tuesday.
>
> It appears as if the "rsync" mirror of CVS is not always "good". It
> seems like "long running" CVS operations (like I'm guessing a full
> tree
> "tag" of REL8_3_STABLE) aren't mirrored "atomically". Of course, CVS
> isn't atomic, so we can't really blame it.
>
> What appears to have happened is that my rsync caught the rsync mirror
> when the tree was "not all tagged", so when the fromcvs went about
> making the new branch on the first appearance of REL8_3_STABLE, it had
> to remove a bunch of files from the branch because they were *not*
> tagged with that symbol in CVS (or at least, not presently tagged with
> that symbol in the rsync mirror of CVS)...
>
> I would guess that any incremental CVS mirror/conversion is going
> to hit
> this at some random time too. Of course, the risk of hitting it
> goes up
> as the frequency of your rsync updates go up.
Hrm... is there a way to momentarily lock-out access to CVS? What I'm
thinking is to have a script that periodically locks CVS access,
takes a snapshot of the tree (preferably via a filesystem snapshot),
and then unlocks. That snapshot would then be used to drive the
mirrors. That would ensure that mirrors always had an atomic view of
things.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
