Re: General question regarding development branches on CVS

[Jim Hyslop]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Farshad Mahjoubi wrote:
>  
> 
> What are good pratices to use cvs as far as concurrent development on CVS:

I usually advise having new feature development continue on the trunk,
even with multiple features, and put maintenance releases on branches.

> 1)       if you want to have multiple features developments how do you do
> it?
Frequent checkins, and frequent updates. In other words, continuous
integration of code.

The general process for each feature is:
- - Establish a basic, do-nothing stub that will eventually become the new
feature, and check it in. If necessary, provide mechanisms to switch off
the code (e.g. in C or C++, perhaps using #ifdef statements).
- - Flesh out the code, keeping it as isolated and modular as possible.
- - Check in frequently (daily, sometimes multiple times per day)
- - refresh your code from the repository at least daily

You can sometimes do this even if feature A is scheduled to be released
before feature B. Doing this does require a little more discipline,
because you have to ensure your development is well-segregated and
isolated. If not, then you can put development of each major feature on
a separate branch. You must make sure you merge frequently from all
development branches onto the trunk.

> 2)      If your release is on a trunk how do u manage your development( can
> it be on a branch)?

It can be, but it's generally easier to keep development on the trunk.
If you keep the release on the trunk and put new development on a
branch, then you'll have to perform a massive merge when it comes time
to release the next version. Massive merges are *very* painful, whereas
small, frequent merges are much more manageable.

> 3)      If your release is on a trunk how do you manage your maintenance
> Branch?

Apply a non-branch tag to the trunk, then apply the branch tag to the
non-branch tag:

cvs tag rel_1_1
cvs tag -b rel_1_1-bt
cvs update rel_1_1-bt

make maintenance changes on the branch and merge back to the trunk as
necessary. Note the naming convention for the tags - the branch tag has
the same name as the non-branch tag, with a "-bt" suffix. I strongly
recommend adopting a convention like this.

The non-branch tag is very important - otherwise you have no way of
referring to the branch point (with the current stable release, at least
- - cvs 1.12.* has a new set of predefined tags that let you find the base
of a branch).

> 
> 4)      If you have two release one called 1.1 and is released on dec15 and
> the other is 2.0 and is released April 2006
> 
> How do you manage that( considering that the development of 2.0 is starting
> now while 1.1 is under development as well)? 

This is a minor variation on my previous recommendation. Instead of
creating the 1.1 branch when 1.1 is released, create the branch now and
move 1.1 development onto that branch. Have development of 2.0 continue
on the trunk. When 1.1 is released, you don't need to create a new
branch, just apply a tag, and the branch is now your maintenance branch.

Make sure you merge frequently from the 1.1 branch back to the trunk,
otherwise you'll have the massive merge problem I mentioned earlier.

No matter which strategy you adopt, you will likely end up having to
merge your code. Some tips on merging:
- - Merge as frequently as possible. Small, frequent merges are much
simpler to resolve than large, infrequent ones.
- - Make the person who initially committed the code responsible for
merging to the mainline (or other branches). DO NOT have one person who
is the only person responsible for merging. The person who wrote the
code is the best qualified to correctly resolve any merge issues.

- --
Jim Hyslop
Dreampossible: Better software. Simply.     http://www.dreampossible.ca
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDb9sFLdDyDwyJw+MRApR1AJsHXnevS47n6IoKPriPcwuPHmdK/wCg+XkX
cuJRLB/oyPRSQMQ+AV8P2xk=
=ZBgC
-----END PGP SIGNATURE-----