Re: CVS branch management (was Re: A problem with new pg_dump)

I have added this to the developer's FAQ.

---------------------------------------------------------------------------

> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> > At 11:22 7/05/01 -0400, Tom Lane wrote:
> >> Do you need a quick lecture on CVS branch management?
>
> > That would be sensible.
>
> OK, some quick notes for those with commit privileges:
>
> If you just do basic "cvs checkout", "cvs update", "cvs commit", then
> you'll always be dealing with the HEAD version of the files in CVS.
> That's what you want for development, but if you need to patch past
> stable releases then you have to be able to access and update the
> "branch" portions of our CVS repository. We normally fork off a branch
> for a stable release just before starting the development cycle for the
> next release.
>
> The first thing you have to know is the branch name for the branch you
> are interested in getting at. Unfortunately Marc has been less than
> 100% consistent in naming the things. One way to check is to apply
> "cvs log" to any file that goes back a long time, for example HISTORY
> in the top directory:
>
> $ cvs log HISTORY | more
>
> RCS file: /home/projects/pgsql/cvsroot/pgsql/HISTORY,v
> Working file: HISTORY
> head: 1.106
> branch:
> locks: strict
> access list:
> symbolic names:
> REL7_1_STABLE: 1.106.0.2
> REL7_1_BETA: 1.79
> REL7_1_BETA3: 1.86
> REL7_1_BETA2: 1.86
> REL7_1: 1.102
> REL7_0_PATCHES: 1.70.0.2
> REL7_0: 1.70
> REL6_5_PATCHES: 1.52.0.2
> REL6_5: 1.52
> REL6_4: 1.44.0.2
> release-6-3: 1.33
> SUPPORT: 1.1.1.1
> PG95-DIST: 1.1.1
> keyword substitution: kv
> total revisions: 129; selected revisions: 129
> More---q
>
> Unfortunately "cvs log" isn't all that great about distinguishing
> branches from tags --- it calls 'em all "symbolic names". (A "tag" just
> marks a specific timepoint across all files --- it's essentially a
> snapshot whereas a branch is a changeable fileset.) Rule of thumb is
> that names attached to four-number versions where the third number is
> zero represent branches, the others are just tags. Here we can see that
> the extant branches are
> REL7_1_STABLE
> REL7_0_PATCHES
> REL6_5_PATCHES
> The next commit to the head will be revision 1.107, whereas any changes
> committed into the REL7_1_STABLE branch will have revision numbers like
> 1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where
> the zero went...).
>
> OK, so how do you do work on a branch? By far the best way is to create
> a separate checkout tree for the branch and do your work in that. Not
> only is that the easiest way to deal with CVS, but you really need to
> have the whole past tree available anyway to test your work. (And you
> *better* test your work. Never forget that dot-releases tend to go out
> with very little beta testing --- so whenever you commit an update to a
> stable branch, you'd better be doubly sure that it's correct.)
>
> Normally, to checkout the head branch, you just cd to the place you
> want to contain the toplevel "pgsql" directory and say
>
> cvs ... checkout pgsql
>
> To get a past branch, you cd to whereever you want it and say
>
> cvs ... checkout -r BRANCHNAME pgsql
>
> For example, just a couple days ago I did
>
> mkdir ~postgres/REL7_1
> cd ~postgres/REL7_1
> cvs ... checkout -r REL7_1_STABLE pgsql
>
> and now I have a maintenance copy of 7.1.*.
>
> When you've done a checkout in this way, the branch name is "sticky":
> CVS automatically knows that this directory tree is for the branch,
> and whenever you do "cvs update" or "cvs commit" in this tree, you'll
> fetch or store the latest version in the branch, not the head version.
> Easy as can be.
>
> So, if you have a patch that needs to apply to both the head and a
> recent stable branch, you have to make the edits and do the commit
> twice, once in your development tree and once in your stable branch
> tree. This is kind of a pain, which is why we don't normally fork
> the tree right away after a major release --- we wait for a dot-release
> or two, so that we won't have to double-patch the first wave of fixes.
>
> Any questions? (See the CVS manual for details on these commands,
> of course.)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026