Re: CVS branches RFC

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Earnie Boyd" <earnie_boyd@yahoo.com>
To: "CD List" <Cygwin-Developers@Cygwin.Com>
Sent: Wednesday, October 03, 2001 10:47 PM
Subject: Re: CVS branches RFC


> Earnie Boyd wrote:
> >
> > Robert Collins wrote:
> >
> > > * cvsmkbranch creates a new branch, from the current sandbox. So
if you
> > > have local changes that are heading from "trivial" to "hmm..." you
can
> > > run cvsmkbranch foo from within winsup to create a new branch.
> >
> > Ok, CWD = winsup/cygwin, I cvsmkbranch Earnie, this copies the CWD
to
> > ../Earnie and creates the branch.  Do I continue to work in
> > winsup/cygwin or do I work in winsup/Earnie?
> >
>
> Also, shouldn't cvsmkbranch ask to add new files not yet added to CVS
> with `cvs add'?

Ok. I'll put this in a file somewhere
(how-branch-development-works.txt?)

For now, in reverse order.
cvsmkbranch should not ask to add new files - it cannot discriminate
between foo.cc which you want and foobar.cc which was an experiment and
is not needed.
cvsmkbranch does a full copy of the folder that you are in, so those
files are copied to the new directory. Then in that dir you run cvs add.

After the cvsmkbranch any work you do in winsup/cygwin will get
committed to the tag that was present before you ran cvsmkbranch - ie
the CWD is unaltered.

So you start working in winsup/Earnie.

Now the problem is that cygwin/winsup have a very integrated source
tree - there are makefile fragments with 'cygwin' hardcoded in em and so
forth. This isn't a bad thing per se, but it requires special handling.

Key points:
1) your current built src is in winsup/cygwin.
2) you may want to work on n different branches at a time.

There are two easy solutions.
Option A: the following commands should be self-evident.

1) mv cygwin cygwin_head
2) ln -s cygwin_head cygwin
3) cd cygwin
4) cvsmkbranch Earnie
5) cd ..
6) rm cygwin
7) ln -s Earnie cygwin

and so on. Now the Makefile dependencies should work fine with this
(they do for me) although a full build is likely when you switch
branches. New files can cause confusion of the 'cannot find foo.h needed
to build dcrt0.cc'. Solution:
$rm dcrt0.d

Option B:
cd cygwin
cvsmkbranch Earnie
cd ../Earnie
cvs add .. && cvs ci ; <get the sandbox and CVS fully synced>
cd ..
rm -rf Earnie
cd cygwin
---remember this---
cvs -z3 up -Pdkk -r Earnie
-------------------
hack. build. test.
ok time to work on head a bit.
1) make sure that all changes in Earnie are committed to cvs, or are
disposable.
use cvs -z3 diff -up to ensure that there are 0 changes in your sandbox.
Remember that on a branch stability is no longer as concerning - partial
code is usually ok. (I try to keep everything compiling and running, but
I'm not worried about committing a function stub to be fleshed out
later, on HEAD I wouldn't do that (ignoring whether Chris would let it
in :] ). )
2) ----remember this ----
cvs -z3 up -PdA -kk
------------------
hack. build. test. Submit to cygwin-patches.
and so on.

Rob