CVS branch management (was Re: A problem with new pg_dump) - Mailing list pgsql-hackers

Philip Warner <pjw@rhyme.com.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 areREL7_1_STABLEREL7_0_PATCHESREL6_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_1cd ~postgres/REL7_1cvs ... 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