[cvsnt] newbie branch/merge question

[Tony Hoyle]

Nick Duane wrote:
> 1. What's the best strategy to implement for branching/merging?  I know 
> that's a pretty open ended question which by itself could have multiple 
> correct answers.  In one of the posts I read the person said they *only* 
> develop in branches.  Let me attempt to give an example in hopes that it 

It depends on how you develop and what works for you.

The basic model is promotion.. so you have development of HEAD, testing 
branch, release branch (sometimes more levels).

In this model all work goes on it HEAD, and when a particular programmer has 
finished some work he promotes to testing by merging his code into it 
(possibly using bugids or limited to a module so he doesn't merge code from 
other developers).

Also in this model no commits are ever done onto the branches, only merges.

Another model is parallel development... cvsnt itself works like be that - 
development (2.6) on HEAD, stable (2.5) on 2_0_x, both branches work in 
parallel and periodically new code in 2_0_x is merged back into HEAD.

Mergepoints make both models a lot easier and the older document will not have 
mentioned those.

> had some initial questions.  First of all it seems that all releases would 
> have to be from a branch as opposed to the trunk.  Is this correct?  I don't 
> see how you could ever get a release from the main trunk as that most likely 
> would have other code changes in it.  For instance, you're about to put 

Depends on your development cycle.  If you can reasonably code freeze and set 
a release date then it's possible to do it on one branch.

Creating a new branch means you're more flexible since your developers for 
3.7.3 can be working at the same time as your developers for 3.7.4.

> 3.7.3 into QA so you create a 3.7.3 branch so that only fixes for the 
> current feature set go into the release as opposed to additional features 
> other developers are working on.  At some later point in time all bugs are 
> fixed and you are ready to release.  You then merge this branch back into 
> the trunk.  However the trunk has additional features in it so you could 
> never get version 3.7.3 from the main trunk.  Is this correct?  Back to my 

Pretty much.  Once you have a 3.7.3 branch that is where you get the releases 
for that release.

> situation.  I was thinking of creating an empty module.  Then I would create 
> a 3.7.2 branch and copy over the vss code into this branch.  Then I would 
> merge back into the trunk.  Obviously this procedure is not needed for this 
> initial version, but I figured it might be good to treat all releases the 
> same.  Then I would create a 3.7.3 branch and copy the 3.7.3 code into that 
> branch.  I would then merge that back into the trunk.  And I would do the 
> same for 3.8.  Comments?

That doesn't sounds like it's likely to work.

Start with one codebase - preferably what you're working on or latest release, 
and import that the repository.  Branch that as its version number, so you for 
example have development (HEAD), and stable (3.8) - that is your starting point.

I can't think of a sensible way to put older releases in as you'd need the 
branch points and differences of each file - which you won't have if you've 
been using vss.

There is a script - vss2cvs - that is supposed to do this kind of thing.  Try 
that first.

> 2. When should you create a branch?  As soon as we do a release should we 
> create a branch for the next release and develop in that branch?  Or should 
> we develop in the trunk and only move to the branch at the point when all 
> the features are completed for a release and we're ready to go into QA?

That's up to you.  Both approaches work, but without knowing your development 
cycle I couldn't recommend one over the other.

> 3. A support group is running CVS 1.11 server.  We can use this server 
> supported by our support group or potentially run our own version of CVSNT 
> on a server.  Is MergePoints enough of a benefit to warrant us running our 
> own version of CVSNT?

IMO branching without mergepoints is working with one hand tied behind your back.

Tony