Re: Status of GIT mirror (Was [HACKERS] having problem in rsync'ing cvs)

[Decibel!]

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

"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)...


as the frequency of your rsync updates go up.

seems like "long running" CVS operations (like I'm guessing a full tree 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

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828

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.

smime.p7s
Description: S/MIME cryptographic signature