[cvsnt] newbie branch/merge question

[Nick Duane]

Thanks.  There is some additional information which I did not indicate which 
comes into play in how I thought I should put our 3.7.2, 3.7.3, and 3.8 
releases into CVS.  I believe 3.7.3 was taken from 3.7.2.  However, 3.8 is 
3.7.2 plus some other changes.  So I can't (at least I think I can't ) just 
commit 3.8 to the HEAD.  I was hoping on using CVS's merging capability to 
merge 3.8 and 3.7.3 for me.

Nick

"Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message 
news:ml5xcfyyaqmi$.dlg at connectionbrazil.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.
>
> Exactly.
>
>> 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... :)
>
> Gerhard