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.
Let me add a bit more. 3.7.2 has alread been released. 3.7.3 is in QA now. 3.8 is scheduled for later this year and there exists changes that have been made to 3.7.2 for this 3.8 release. There are additional changes that will be in 3.8. In addition we need to merge the 3.7.3 changes into this 3.8 code base. Don't know if I made this more or less clear with this explanation. I guess this type of situation shouldn't be too rare as it appears it will happen when you have parallel development on multiple releases (I think). What I want to end up with is: 1. A 3.7.2 branch that contains the 3.7.2 release should we ever need to make changes to that. 2. A 3.7.3 branch that contains the 3.7.3 release should we ever need to make changes to that. 3. A trunk that contains the current 3.8 changes merged with 3.7.3. I guess I could do the following to accomplish this: a. Copy the 3.7.2 release to the trunk. b. Create a 3.7.2 branch. c. Create a 3.7.3 branch and copy the 3.7.3 code into that branch. d. Create a 3.8 branch and copy the 3.8 code into that branch. e. Merge the 3.7.3 branch with the trunk. f. Merge the 3.8 branch with the trunk. g. Merge the trunk with the 3.8 branch. These steps also give me a 3.8 branch and I'm not sure I want this as I have to do bi-directional merging which I think a reply to this post said I should stay away from. Thanks, Nick "Nick Duane" <nickdu at msn.com> wrote in message news:ebnf1h$vb1$1 at paris.nodomain.org... > 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 > >