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: > 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. That, and you have three merges, two of which are not necessary. While merging is not all it is feared to be, it is something you don't want to do if it's not necessary :) Maybe like this: - Copy the 3.7.2 release to the sandbox, add all files. Test build and commit. - Tag it. Maybe wait with the branch until you need it, or create it right now. This is your current release that's out there. When/if you need it, create the branch starting at this tag. (Whenever I start a branch, I first create a tag anyway, like explained in my other message.) - Create the root tag for the 3.7.3 branch. (This is the same code as the 3.7.2 tag, but for naming convention reasons I would use a separate tag here -- see my other message.) Create the 3.7.3 branch and update to it. (It now contains the 3.7.2 code.) - Make the sandbox the 3.7.3 release. Determine which files need to be added and removed. (In my other message I described two methods how to do this.) Add and remove them. Test build and commit. This is now your current 3.7.3 release. - Tag it. This is your tag for this version. Once you have more changes on this branch, you may want to be able to go back to this release. QA, testers and bugfixers work on this 3.7.3 branch. This is also where your 3.7.3 release will be. You will want to tag every published release on this branch. - Put your sandbox back on HEAD. (At this point, that's still the 3.7.2 release.) - Make the code the current 3.8 code. Determine which files need to added and removed. (In my other message I described two methods how to do this.) Add and remove them. Test build and commit. - Tag it. This is now your current 3.8 development code, that's why it is on the trunk (HEAD). The code in HEAD now contains the 3.8 code, which contains the 3.7.2 code implicitly, plus a number of 3.8 changes. - Now merge in the 3.7.3 branch. This will add to the code in HEAD (3.8) all changes that happened between 3.7.2 (branch root) and 3.7.3 (current branch tip). It will also create a merge point between the current 3.7.3 branch tip and HEAD. - Fix the merged code. Test and build. Commit. - Tag it. This is now your up to date development code, containing all implemented features and fixes. Only one merge needed. (This is basically a slight variation of what Bo suggested.) For all future updates to the 3.7.3 branch, you just repeat this last merging process to merge any changes that happen on that branch back to HEAD (where the 3.8 development happens). Once 3.8 is ready for QA, just tag and branch it, so that the QA people can work on their branch towards a release. Gerhard