[cvsnt] newbie branch/merge question

Gerhard Fiedler lists at connectionbrazil.com
Sat Aug 12 00:28:52 BST 2006

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Nick Duane wrote:

> 1. What's the best strategy to implement for branching/merging?  

As you say, there are several possible models, and which one is "right"
depends a lot on your work flow.

> In one of the posts I read the person said they *only* 
> develop in branches.  

May have advantages if developers or groups of developers work largely
independently on bigger features. One advantage may be that people get used
to merging. 

> First of all it seems that all releases would have to be from a branch as
> opposed to the trunk.  

That's what probably most do.

> For instance, you're about to put 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.  

You don't have to wait with the merge until all bugs are fixed. You can
just as well merge every individual fix back to the trunk, or any set of
fixes. Just keep in mind that cvsnt works best if you only ever merge in
one direction between branches (in this sense the trunk is a branch, too,
just a special one).

> However the trunk has additional features in it so you could never get
> version 3.7.3 from the main trunk.  

Correct. It is on the branch you created for it.

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

Doesn't sound real good. If the import of history with the vss2cvs script
doesn't work, I would probably try the following. Take the 3.7.2 code and
commit it to HEAD. Create the 3.7.2 branch from that. Take the 3.7.3 code
and commit it to HEAD. Create the 3.7.3 branch from that. Take the 3.8 code
and commit it to HEAD. That's then your current development branch (or so
it seems to me).

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

Both can work. There is no difference between working on a created branch
and working on the trunk (the default branch). You obviously only have to
create a branch at a point when there are two lines of development. When
that is depends on your situation. If one group continues to work on the
current release features and another one already works on some far-out
features for a future release, that might be the point to create a branch
for the current release group -- or for the far-out group. 

> Is MergePoints enough of a benefit to warrant us running our own version
> of CVSNT?

Yes. Merging is scary enough for VSS newcomers (usually), so if you can
make it easier... :)


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook