RE: General question regarding development branches on CVS

[Farshad Mahjoubi]

Thanks Jim

> From: Jim Hyslop wrote:
>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.


        For your detailed email very informative, I guess I have question
regarding frequent merges if you can elaborate on that.

        I have branched of 6 projects which they combine one product to be
shipped soon, we do integration builds every Wednesday and Friday tag
everthing and build/test it. The developers work on this branches and
edit/submit code and we will have to do big merge to trunk soon.

        1) How can you manage frequent merges? 

        2) Do I need to retag everything and do extra build in trunk now to
make    sure the trunk is healty?

Thanks again
Farshad

-----Original Message-----
From: Jim Hyslop [mailto:address@hidden 
Sent: Monday, November 07, 2005 5:54 PM
To: Farshad Mahjoubi
Cc: address@hidden
Subject: Re: General question regarding development branches on CVS

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