Обсуждение: RE: [HACKERS] vacuum process size
The reason for the tag as to be able to return to the 6.5 release source code. It's production code, and should be accessible at least for the next couple of months. Was a tag created for 6.5.1? The object is to be able to check out any particular release, bugs and all, whenever we feel like it. MikeA >> >> >> Tatsuo Ishii <t-ishii@sra.co.jp> writes: >> > Just for a confirmation: I see REL6_5_PATCHES and REL6_5 Tag in the >> > CVS respository. I thought that REL6_5_PATCHES is the Tag >> for the 6.5 >> > statble tree and would eventually become 6.5.2. If so, what is the >> > REL6_5 Tag? Or I totally miss the point? >> >> Right, REL6_5_PATCHES is the 6.5.* branch. REL6_5 is just a tag --- >> that is, it's effectively a frozen snapshot of the 6.5 release, >> not an evolvable branch. >> >> I am not sure if Marc intends to continue this naming convention >> in future, or if it was just a mistake to create REL6_5 as a tag >> not a branch. I don't see a whole lot of use for the frozen tag >> myself... >> >> regards, tom lane >> >> ************ >>
On Wed, 25 Aug 1999, Ansley, Michael wrote:
> The reason for the tag as to be able to return to the 6.5 release source
> code. It's production code, and should be accessible at least for the next
> couple of months.
>
> Was a tag created for 6.5.1? The object is to be able to check out any
> particular release, bugs and all, whenever we feel like it.
Never did v6.5.1...but I have no problem with starting to do this on minor
releases to, since...
Could someone try out the following patch?
ftp://ftp.postgresql.org/pub/postgresql-6.5-6.5.x.patch.gz
It is a patch against v6.5 that will bring it up to the most stable
version *if* it worked right. Reading through the patch, everything looks
good, but...
If this actually works, we just might have a way of saving ppl downloading
5Meg files on minor releases, as the above is <100k :)
>
> MikeA
>
>
>
> >>
> >>
> >> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >> > Just for a confirmation: I see REL6_5_PATCHES and REL6_5 Tag in the
> >> > CVS respository. I thought that REL6_5_PATCHES is the Tag
> >> for the 6.5
> >> > statble tree and would eventually become 6.5.2. If so, what is the
> >> > REL6_5 Tag? Or I totally miss the point?
> >>
> >> Right, REL6_5_PATCHES is the 6.5.* branch. REL6_5 is just a tag ---
> >> that is, it's effectively a frozen snapshot of the 6.5 release,
> >> not an evolvable branch.
> >>
> >> I am not sure if Marc intends to continue this naming convention
> >> in future, or if it was just a mistake to create REL6_5 as a tag
> >> not a branch. I don't see a whole lot of use for the frozen tag
> >> myself...
> >>
> >> regards, tom lane
> >>
> >> ************
> >>
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> The reason for the tag as to be able to return to the 6.5 release source
> code. It's production code, and should be accessible at least for the next
> couple of months.
> Was a tag created for 6.5.1? The object is to be able to check out any
> particular release, bugs and all, whenever we feel like it.
You can always do a checkout by date if you need to capture the state of
the cvs tree at some particular past time. Frozen tags are just a (very
inefficient) way of remembering specific past times that you think are
likely to be of interest.
regards, tom lane
On Wed, 25 Aug 1999, Tom Lane wrote:
> "Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> > The reason for the tag as to be able to return to the 6.5 release source
> > code. It's production code, and should be accessible at least for the next
> > couple of months.
> > Was a tag created for 6.5.1? The object is to be able to check out any
> > particular release, bugs and all, whenever we feel like it.
>
> You can always do a checkout by date if you need to capture the state of
> the cvs tree at some particular past time. Frozen tags are just a (very
> inefficient) way of remembering specific past times that you think are
> likely to be of interest.
Okay, you lost me on this one...why is it inefficient to tag the tree on
the date of a release vs trying to remember that date? *raised eyebrow*
In fact, vs trying to remember the exact date *and* time of a release?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> Okay, you lost me on this one...why is it inefficient to tag the tree on
> the date of a release vs trying to remember that date? *raised eyebrow*
> In fact, vs trying to remember the exact date *and* time of a release?
Because you make an entry "REL6_5 => something or other" in *every*
*single* *file* of the CVS tree. It'd be more logical to store
"REL6_5 => 25 Aug 1999 11:55:32 -0300 (ADT)", or some such, in one
place. Dunno why the CVS people didn't think of that.
Inefficient though it be, I agree it's better than trying to remember
the release timestamps manually.
I'd suggest, though, that from here on out we use the short strings
like "REL6_6" for the branches, since people have much more need to
refer to the branches than specific release points. Tags for releases
could maybe be called "REL6_6_0", "REL6_6_1", etc.
regards, tom lane
The Hermit Hacker wrote: > Never did v6.5.1...but I have no problem with starting to do this on minor > releases to, since... > > Could someone try out the following patch? > > ftp://ftp.postgresql.org/pub/postgresql-6.5-6.5.x.patch.gz > > It is a patch against v6.5 that will bring it up to the most stable > version *if* it worked right. Reading through the patch, everything looks > good, but... Great idea! It will be good practice - to have simply patches for minor versions. But this is definitely not a patch for 6.5.0, but some other version. Unfortunately I lost .tar.gz 6.5.0 distribution, but I am pretty sure that my sources were intact. There were a lot of hunks failed, and patched version failed to compile. Isn't is the right way to do a patch: take old distribution and simply make a diff against new tree? Seems that current patch isn't done that way. Included here is patch log file for your reference. -- Leon.