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

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