Re: Several tags around PostgreSQL 7.1 broken - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Several tags around PostgreSQL 7.1 broken
Date
Msg-id 20080402101059.66375e87@mha-laptop
Whole thread Raw
In response to Re: Several tags around PostgreSQL 7.1 broken  ("Marc G. Fournier" <scrappy@hub.org>)
Responses Re: Several tags around PostgreSQL 7.1 broken  ("Marc G. Fournier" <scrappy@hub.org>)
List pgsql-hackers
Marc G. Fournier wrote:
> - --On Tuesday, April 01, 2008 14:06:09 -0400 Tom Lane
> <tgl@sss.pgh.pa.us> wrote:
> 
> > Peter Eisentraut <peter_e@gmx.net> writes:
> >> In the meantime, does anyone have more information about how this
> >> came about?
> >
> > Marc's always done both the tagging and the tarball-making, so you'd
> > have to ask him about that.  I believe he's made it more scripted
> > over the years, so this might reflect a manual foulup that
> > (hopefully) is no longer possible.
> 
> Ya, I'll go with that (considering 7.1 was back in 2001 ... ) ...
> but, from the way Peter describes it (taging partially checked out
> code), I'm not 100% how its possible to 'foul up' ... a tag operation
> is:
> 
> cvs -q update -APd .
> cvs -q tag REL7_1 .
> 
> unless its a sub-tagging, which would have:
> 
> cvs -q update -rREL7_1_STABLE -Pd .
> cvs -q tag REL7_1_1 .
> 
> And since I don't do the update until things are "quiet" (generally
> when Tom has finished his last commit before release), I'm not sure
> how I could have gotten a 'partial checkout' ...

Could it be that a commit was done while the tag operation was running?
Given that neither is an atomic operation in cvs, and it used to be
that large repo operations could take quite a long time?

//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong