[cvsnt] Re: Branch merging - this seems wrong...

[Tony Hoyle]

Tony Eva wrote:
> Umm... I think we have a failure to communicate here, because
> that's what I said (or thought I said).  However, we do seem
> to agree that the developers work on a development branch
> (perhaps several development branches).  Let us assume that

Normally there would be one development branch.  In fact it's difficult 
to imagine a scenario where there would be multiple ones... if your 
developers depend on each other they must be on the same branch.  If 
your developers are working on completely independent code then they 
might as well be in the same branch as they won't conflict.

> the intention is for the work that is done on the development
> branch to be added to the stable branch when it (the
> development branch) is tested and stable.  That means there
> must be at least one merge from the development branch back
> to the stable branch, not so?  Otherwise the development will
> never be included in the stable build.

Yes but there's never a merge from the stable to development.

> So it is fair to postulate a series of merges from the stable
> branch to the development branch, culminating in one merge
> back from the development branch to the stable branch at the
> end.

No it isn't - stable is stable and is the tested results of development. 
  If there is every anything in stable has not come from development 
then something is badly wrong.

> This is the scenario that CVS does not seem to handle -
> specifically, the one final merge back to the stable branch,
> where in my view the ancestor (or merge base point) is
> incorrectly determined.

It is absolutely correct and it *is* an unsolvable problem.  I explained 
why before with a separate example.  Here's another more complex one 
(that may end up in the ebook at some point):

Branch B
Start feature changes, Commit a few times
Merge from A
More changes to incorporate changes to A.  Had to bugfix A as it broke
your changes.
More feature development.
Merge from A
Feature gets tested
Merge from A.
Changes to fix feature as it broke again.
Feature gets tested.
Merge from A.
Test passed.
Merge back to A.

This shows several points:

1.  Merging from the mergepoint would completely lose all the changes. 
You *must* merge from the branchpoint.
2.  The methodology used has caused conflicts because the developers 
weren't in communication - the final merge may break the tree entirely 
because the developer had to change code that wasn't his own to make his 
code work.

Tony