[cvsnt] newbie branch/merge question

[Nick Duane]

First of all let me say thank you to everyone who has been helping me 
through my introduction to CVS.

Let me add a bit more complexity to this before letting this post rest in 
peace.  I have also made some changes to 3.7.2 centered around cleaning up 
the build.  Ideally I would like these changes applied to a 3.7.2 build in 
CVS (maybe called 3.7.2.5) so that I can get back to it later.  For sure I 
need these changes applied to the current 3.8 code base.  So with that being 
said would the following be reasonable?

* Add current 3.7.2 code to CVS
* Tag as 3.7.2
* Create 3.7.2 branch at 3.7.2 tag
* Apply my changes to trunk
* Tag as 3.7.2.5
* Create 3.7.3 branch from 3.7.2 tag
* Copy 3.7.3 code to 3.7.3 branch
* Merge 3.7.3 into trunk
* Tag as 3.7.3.5
* Create 3.8 branch from 3.7.2 tag
* Merge trunk into 3.8 branch
* Apply new tag to 3.8 branch

Now 3.8 branch should be the 3.8 changes applied to 3.7.2 plus my changes to 
clean up the build plus the 3.7.3 changes.

By the way, my changes consists of several renamed directories and files 
(copy and delete) as well as other changes.  Not sure how well 
directory/file renames merge.

Sorry if this has gotten a bit convoluted.

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