[cvsnt] newbie branch/merge question

[Nick Duane]

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