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