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