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

I have added this to the developer's FAQ.

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

> 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 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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026