[cvsnt] newbie branch/merge question

[Gerhard Fiedler]

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