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

[Tony Eva]

Warning: long post, sorry...

In reply to Tony Hoyle:

Can I just clarify my terms here?  I think we might be at
cross-purposes in our understanding of the different branch
types.  This is how I refer to them:

'Development' = a branch used essentially as a place for a
developer to save their working copy while they are in the
process of writing and testing their code.  The code
committed to a development branch is work in progress:
highly unstable and subject to change.  Development branches
are short-term and related to a single feature or bug.

'Stable' = a branch used as a collection point for code that
developers are satisfied is complete and working as far as
they can test. It is stable in the sense that it compiles,
and probably will pass any automatic testcases.  Developers
merge their code to the stable branch only when they are sure
that it will not break compilation or auto testcases.
*However*, the code has not yet been fully system tested and
is not ready for customer release.  Many development teams
use HEAD as their stable branch.  (I think this might be what
you are calling the development branch.)

'Candidates' and 'Releases' = often done by tagging the
stable branch, these represent freezes of the code to
undergo full system/verification testing in preparation for
full release.  Sometimes separate branches may be used for
candidate and release code; if so, developers never merge
code directly into these branches in case they break the
testing that has been done on them so far. (I think that
when you refer to the stable branch, this is the type you
mean.)

So in these terms, a development branch is right down at the
bottom of the pecking order.  Because of its instability, it
isn't practical or desirable for developers to share a
development branch.  Each developer is working towards
the goal of getting their code ready for addition to the stable
branch; and to do this, they must periodically make sure that
their development branch is 'up to date' by merging to their
own development branch any code that other developers have
recently added to the stable branch.  In this way they make
sure that when they merge their code into the stable branch,
there are no surprises and nothing breaks.

It is possible (even likely) that when such an 'updating'
merge is done from the stable branch to the developer's
branch, developer B might find that changes on the
stable branch made by developer A have affected his code -
a conflict has arisen in some library code, maybe, or
perhaps A has changed some core function such that B has to
revisit his design.  Under these circumstances A and B will
talk to each other, agree how to resolve the problem, and B
will make changes *on his development branch* such that
when his code is included, A's code will continue to
function properly.

Then when B is confident that he is up to date with the
stable branch, he puts his code into that branch by
merging back.  The code that he merges back will contain
the changes necessary to get his code and A's code to
work together, i.e. A's code has been changed, but this
has been done in consultation with A.  Also B has verified
code stability (compilation, testcases) *before* anybody
else is affected.

I hope this makes things a little less confused.

-- 
Tony