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

[Tony Eva]

Tony Hoyle wrote:
> Normally there would be one development branch.
> [...]
> Yes but there's never a merge from the stable to development.
> [...]
> No it isn't - stable is stable and is the tested results of 
> development. 

I think there may be a misunderstanding of what I mean by
'stable' and 'development - see previous post.

> 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.

What changes have been lost?  All the original commits to A are
still there, and the head of A now has the necessary changes to
allow A and B to work together.  What would the merge from the
branchpoint have saved?

> 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.

That's normal code development - features often interact, or
use common (library) code in conflicting ways that need to be
resolved.  In these circumstances, B would if possible discuss
the problems with the relevant designer before making the
changes; at any rate, it is B's responsibility not to break the
existing functionality on A when he merges back.

-- 
Tony