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