Re: [HACKERS] Developer setup, what works? - Mailing list pgsql-hackers

I've seen several people give some fairly (IMHO) icky "solutions" to
this.

I consider them icky because they didn't support the following:
- local availability of "cvs log" messages
- local availability of cvs branches (may not be important if pgsql
  doesn't use many branches, but this was an absolute requirement with
  the FreeBSD repository)
- ability to commit partial changes of a work in progress easily without
  upsetting the main cvs branch.  (This was required since we often had
  a number of people locally using or working on these changes).


I only know of two ways to do this:

1) setup and use cvs in client mode assuming that pgsql has (or can)
   setup their cvs to act as a server.

One drawback to this for David is that he will be working on a long term
project which will break things if he commits them to the main branch
(and he won't want to keep all his changes uncommitted if he's smart).
A simple solution to this is that he could use a branch in the main
repository and merge that into the main branch when he's all done.  This
would be ideal assuming David's got a fast connection to postgresql.org
and there are no security problems with the postgres cvs gods allowing
cvs client access.

If no body else will be working on the same branch then there isn't a
need to have the changes go to the main pgsql tree right away so it
may be better to do the following:


2) setup a local cvs repository, use cvsup to keep all the bits up to
   date with the main pgsql repository.  David creates a local branch
   (see caveat bellow) and puts all changes there.

Whenever he feels like syncing the source he's working on he runs cvsup
and either
a) merges changes from the main branch into his branch on his tree
or
b) merges his changes into a new branch on the head (I prefer this method).

CVS assists with either of these operations making them mostly painless
except, of course, if there are conflicting changes.

When he's all done and wants his work committed to the main branch he
does one of the above and then he can trivially generate a huge patch
relative to the current head of the main repository suitable for anyone
to commit.  (Or you could do fancy tricks with cvsup to get David's
branch into the main tree in order to keep his intermediate commit
messages).


Caveat:

The problem with this (that no one here has mentioned how to get
around) is that with the "delete" option cvsup will blow away any
local changes you make since if the checksum on the resulting files
don't match it resends the whole file.  Okay, so you remove the "delete"
option, right?  Only partially correct.  Cvsup will still blow away any
changes with the same revision numbers.

Here's an example of what happens:

1) cvsup fetches version 1.69 of a file
2) you locally make changes and commit version 1.70 of this file
3) everything is cool until some time later when someone commits 1.70 to
   the pgsql main repository then:
4) cvsup fetches version 1.70 and blows away your version 1.70

So how do you get around this?  Simple (sort of) you create a branch
point.  Now your changes go to 1.69.0.1, 1.69.0.2, etc.  Cvsup will
merrily add 1.70, 1.71, etc without disturbing your 1.69.0 branch.
EXCEPT if there is a branch created in the main tree at the same point
(thereby causing a collision of version numbers).

To avoid this you can make a small change to your local cvs program to
use a higher branch number instead of starting at zero.  For example,
make it use 1.69.42.1, 1.69.42.2, etc, that way for a collision to occur
the main pgsql repository must be branched more than 20 times at a
single point (cvs uses only even numbers for branching).



For those that are lost here is a step by step summary of what I've done
with the FreeBSD repository in the past (modified here to work with the
pgsql repository):

My $CVSROOT=/cvs (created long ago via cvs init) and I want the pgsql
repository to be rooted at $CVSROOT/pgsql.  Change the appropriate paths
bellow to match whatever you prefer.

Create a pgsql.cvsup file as follows:

pgsql   release=cvs host=postgresql.org base=/cvs/pgsql prefix=/cvs \
        backup compress use-rel-suffix

Note:  This is actually a single line, I'm not sure if cvsup understands
the '\' character.
Note2: There is no delete option present.

The "base" argument tells cvsup were to create a "sup" subdirectory
for it's bookkeeping (here it is put in /cvs/pgsql/sup). The "prefix"
argument is where to dump the actual files, since all the pgsql files
start with pgsql/ this actually puts everything into /cvs/pgsql


If you didn't add pgsql to the root of the local cvs repository (as I
did) then add something like this to the modules file:
pgsql    -a path_from_cvsroot_to/pgsql


Run cvsup to fetch the files.  (I do "cvsup -g -P - pgsql.cvsup")

Checkout the version you want to work from (probably the head).

Tag the branch point:
% cvs tag BLAH_BLAH_BP

Create the branch:
% cvs tag -b BLAH_BLAH

Now work on the files and commit things whenever you like.  Run cvsup as
often as you like and when you want to sync your working sources up do
one of the following:

a) merge changes between the branch point and the head into your branch:

(add an -r option to the rtag command if you don't want to use the head
of the main branch)
% cvs rtag some_tag pgsql
% cvs update -j BLAH_BLAH_BP -j some_tag

Next time use:
% cvs rtag some_other_tag
% cvs update -j some_tag -j some_other_tag

The extra tags are required so that you don't try merging the same
changes multiple times.  (There may be a better way to do this, I've
never actually done it this way).

Instead I do:

b) merge changes on your local branch to a new branch

Get the head (or use a -r option if you don't want the head)
% cvs update -A

Create a new branch
% cvs tag NEW_BRANCH_BP
% cvs tag -b NEW_BRANCH

Merge in your own changes
% cvs update -j BLAH_BLAH_BP -j BLAH_BLAH


This merge operation can happen as often as you like since it's mostly
automatic (although the tag operations can take awhile).  With FreeBSD
I used the (b) approach and did the merge every time there was a new
stable release.

ie I did:
% cvs update -rRELENG_2_2_6
% cvs tag DDM_2_2_6_BP
% cvs tag -b DDM_2_2_6
% cvs update -j DDM_2_2_5_BP -j DDM_2_2_5

Occasionally I'd use cvs to merge in specific important changes without
merging everything else.


When you want to submit things to the main pgsql repository you can
create a huge diff like this:

% cvs diff -uN -r LAST_BRANCH_BP -r LAST_BRANCH


This may seem overly complicated but I found it worked quite well with
the FreeBSD repository.  If you don't fully understand branches under
cvs I highly suggest a full reading of the cvs.info file.

Hope this helped.
--
Dave Chapeskie, DDM Consulting
E-Mail: dchapes@ddm.on.ca