Re: [HACKERS] CVS - Mailing list pgsql-hackers

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> Once a new tag or release has been applied to the CVS tree, is a new
> checkout required, or can I just update with the new tag?  Do I need to
> specify a tag when updating?  If not, which branch is used?  Are there
> separate branches for 6.5 bug-fixes and 6.6 development?

The tip of the tree (checkout with no branch or tag) is always the
latest code; currently it is 6.6-to-be.  For the last couple of versions
we have made a practice of starting a branch for back-patch corrections
to existing releases.  For example:
                  6.3                   |                   |                  6.4                   |  \
   |   6.4.1                  6.5     \                /  |       6.4.2          6.5.1    |         /      current
6.5.2??       |
 


(In this case, since we didn't split the tree until almost 6.5.1
release time, the left-side branch actually diverges from below 6.5.)

So: "cvs checkout pgsql" for latest and greatest; "cvs checkout -rREL6_4
pgsql" for the 6.4 stable release series; "cvs checkout -rREL6_5_PATCHES
pgsql" for the 6.5 branch.  (Marc will have to answer for the
inconsistency in the branch tags ;-).)  Do this in separate directories
if you want to keep more than one workspace.  For example I currently
have/users/postgres/pgsql/...        current sources/users/postgres/REL6_5/pgsql/...    6.5 branch

so I really didmkdir REL6_5cd REL6_5cvs checkout -rREL6_5_PATCHES pgsql
to get a working copy of the 6.5 branch.

Once you've done any of those, a simple "cvs update" within the toplevel
pgsql directory will get you updates appropriate to the branch --- since
branch tags are "sticky", cvs knows which branch to pull.

In particular, to answer your question: the fact that a branch was
created last week doesn't affect the status of a checkout of the tip.
It's still the tip, free of sticky tags.

If there is any further activity in the 6.5 branch, it'd be to produce a
6.5.2 bug-fix release.  We don't generally do that except for really
critical bugs, since double-patching a bug in both the tip and a branch
is a pain.

(The commercial-support venture might result in more bugfix activity
on old branches, since I believe one facet of that idea is better
support of stable releases, but not much has changed yet.)

As far as I know, no one is currently using branches for work that
will eventually be merged back to the main branch, but it could be
done if we had any subtasks being shared by many people.  (The
dreaded fmgr interface change may have to go like that...)

There are also tags for some specific past milestones (use cvs log on a
few files to see what they are), but they're a little bit haphazard.
        regards, tom lane