CVS

Good question. I was going to do a fresh checkout tomorrow, but it would
be interesting to know about this.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Ansley, Michael [mailto:Michael.Ansley@intec.co.za]
Sent: 19 July 1999 09:41
To: 'pgsql-hackers@postgresql.org'
Subject: [HACKERS] 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

On Mon, 19 Jul 1999, Peter Mount wrote:

Good question. I was going to do a fresh checkout tomorrow, but it would
be interesting to know about this.

If you do a fresh checkout, it will take the 'current' or 'ongoing' trunk
of the tree...if you want to work on a branch, you have to stipulate the
-r option to check that one out seperately...

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.

-----Original Message-----
From: Ansley, Michael [mailto:Michael.Ansley@intec.co.za]
Sent: 19 July 1999 09:41
To: 'pgsql-hackers@postgresql.org'
Subject: [HACKERS] 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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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 did
mkdir REL6_5
cd REL6_5
cvs 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

This was exactly what I was looking for, thanks Tom.

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?? |

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.

Double-patching is a pain, but I thought that that was the point of using
CVS to do your branching. AFAIK, CVS will merge the bug-fixes in, say, the
6.5.1 branch back into the main branch. Because you want to fix the bugs in
6.5 into 6.5.1, without having to double-patch, but new development must
only go into the main branch. So, when 6.5.1 is released, it is merged back
into the main branch to pass the fixes over, and also carries on to 6.5.2 in
a continuation of the existing branch.

Anyway, ideas for Marc.

Thanks again, this is great. Should go into the developers docs.

MikeA

Good question. I was going to do a fresh checkout tomorrow, but it would
be interesting to know about this.

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?

Current 6.6 is cvs without tags. 6.5.1 is tag REL6_5_PATCHES.

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

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

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:

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.

Double-patching is a pain, but I thought that that was the point of using
CVS to do your branching. AFAIK, CVS will merge the bug-fixes in, say, the
6.5.1 branch back into the main branch. Because you want to fix the bugs in
6.5 into 6.5.1, without having to double-patch, but new development must
only go into the main branch. So, when 6.5.1 is released, it is merged back
into the main branch to pass the fixes over, and also carries on to 6.5.2 in
a continuation of the existing branch.

The trouble is that the tip usually diverges fast enough that mechanical
application of the same diffs to tip and stable branch doesn't work
very well :-(.

Also, our usual practice is to prove out a bugfix in the tip and then
consider whether to apply it to stable branches. I'm not sure whether
CVS supports that as easily as merging a branch to the tip, but I'd
be *really* wary of mechanical diff transfer to stable branches...
if the diff extracts too little or too much of the changes in the
tip file, you might not find out till too late.

regards, tom lane

Thanks all for this info. I'm presuming that, because no-one has been rude
yet, that a lot of this is not in the developers manual, or FAQ yet. Would
it be worthwhile putting it there? Just a quick paragraph with the latest
settings, and default options for particular types of developers (e.g.:
somebody who wants to hack the source and contribute, somebody who wants the
latest patch tree, somebody who wants access to the latest source, but no
contributions, etc).

MikeA

Thanks all for this info. I'm presuming that, because no-one has been rude
yet, that a lot of this is not in the developers manual, or FAQ yet.

Naw, we're just a bunch of polite people, at least today ;)

Would
it be worthwhile putting it there? Just a quick paragraph with the latest
settings, and default options for particular types of developers (e.g.:
somebody who wants to hack the source and contribute, somebody who wants the
latest patch tree, somebody who wants access to the latest source, but no
contributions, etc).

Please look at the appendix entitled "The CVS Repository". The source
is in cvs.sgml (and the derived html or hardcopy appendix is in the
integrated docs or developer's guide). Any and all updates or fixes or
rewrites would be welcome. Also, we should have a good cross-link to
it on the web page if we don't already.

Perhaps current values could go into the FAQ, but the general
principles and today' settings should be in the main docs. So far,
we've had enough docs changes that we get new "big docs" for every
release, though sometime (way in the future) we might have things
settle down and be able to not update them every release.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California