[cvsnt] newbie branch/merge question

[Nick Duane]

Thanks.  So I take it HEAD is another name for trunk?

Nick

"Tony Hoyle" <tony.hoyle at march-hare.com> wrote in message 
news:ebipb2$f2h$1 at paris.nodomain.org...
> 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