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

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Status of GIT mirror (Was having problem in rsync'ing cvs)
Date: 2008-03-27 15:47:12
Message-ID: 20080327154711.GO6497@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Brendan Jurd <direvus(at)gmail(dot)com> [080326 10:19]:
> On 27/03/2008, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-03-27 15:52:34 Re: Patch queue permenent URLs
Previous Message Simon Riggs 2008-03-27 15:44:58 Re: Patch queue permenent URLs