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.
This looks good, thanks! I think I'll give this a shot. I'll do a dry run first on my own test server. As I stated in a previous post we may end up having to use cvs 1.11 which I guess will make branching/merging a bit trickier, but as long as we follow a set of guidelines I'm hoping we should be ok. Nick "Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message news:x6rxdjc5drs3.dlg at connectionbrazil.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