Thread: CVS
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? MikeA
> 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?
If you want to continue working out of the main branch, you can just
do a
cvs update -PdA pgsql
to get the latest updates. If you want to work on the REL6_5_PATCHES
branch, you will need to do a separate checkout (afaik), using
cvs checkout -rREL6_5_PATCHES pgsql
and, of course, you will then be working out of the branch, and never
see the main branch again. The branch tags are "sticky", so after
checking out REL6_5_PATCHES a subsequent
cvs update -Pd pgsql
will continue to get you that branch.
That is another reason why using CVSup to maintain a local copy of the
cvs repository is so convenient; it maintains info on all branches, so
there is no extra work over the network to check out another branch.
btw, although I recommended using the "-PdA" set of switches when
working on the main branch, the "-A" is in fact somewhat dangerous in
the sense that once you have checked out a branch such as
REL6_5_PATCHES then an inadvertent update using "-A" will have you
looking at the main branch instead. It may be better to not use that
switch at all...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
"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
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> If you want to continue working out of the main branch, you can just
> do a
> cvs update -PdA pgsql
BTW, you can stick any switches you use standardly into a ~/.cvsrc
file in your home directory. Mine contains
cvs -z3
update -d -P
checkout -P
which gives -z3 as a global option to all cvs commands (good for remote
usage of hub.org, but a waste of cycles if you are using a local CVSup
directory) plus -dP for updates and -P for checkout, which are necessary
for sane treatment of subdirectories IMHO. So I just say "cvs update"
and worry not...
regards, tom lane