* Brendan Jurd <direvus@gmail.com> [080326 10:19]:
> On 27/03/2008, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
> > Is the rsync daemon on anoncvs down? Is everyone else able to do rsync?
> >
>
> Possibly related; the Postgres git repository at
> http://repo.or.cz/w/PostgreSQL.git is showing the last commit at 25
> hours ago. It's usually a bit more spry than that.
Oops - no, that's just me...
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.
And I just forgot to re-enable my cron after I finished looking at it.
BTW, anybody following the GIT mirror, the REL8_3_STABLE branch has been
re-wound, you you'll probably have to force update it (git fetch -f) if
you only accept fast forward updates on fetches (the default).
And if you have patches based on REL8_3_STABLE, you'll need to rebase
them too. Of course, seeing as the tree in REL8_3_STABLE mirror was
broken, I suspect the set of people using it was 0.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
