Skip site navigation (1) Skip section navigation (2)

Re: Several tags around PostgreSQL 7.1 broken

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Several tags around PostgreSQL 7.1 broken
Date: 2008-04-02 08:10:59
Message-ID: 20080402101059.66375e87@mha-laptop (view raw or flat)
Thread:
Lists: pgsql-hackers
Marc G. Fournier wrote:
> - --On Tuesday, April 01, 2008 14:06:09 -0400 Tom Lane
> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 
> > Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-04-02 08:58:59
Subject: Re: bug in float8in()
Previous:From: NikhilSDate: 2008-04-02 07:23:27
Subject: Re: Problem identifying constraints which should not be inherited

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group