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

Tony Eva teva at Airspan.com
Tue Jun 6 09:40:31 BST 2006

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Tony Hoyle wrote:
> That's what you have the development branches for - 
> developers should be working on that not the testing/stable 
> branches (in fact in that scenario there would *never* be a 
> commit directly to a stable branch).

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

So, if that is the case, then what happens if the development
is significantly complex and takes a long time, and while it
is taking place, other developers are merging from their
completed development branches to the stable branch?  It's
reasonable to assume that our developer will want to include
their stable code in his development branch so that he is
working with an up-to-date stable baseline, and so that he
doesn't get left with an horrendous merge at the end.

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

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.

> Once you branch it's a separate line of development - 
> branches are there precisely for when you do *not* want to 
> track the commits on the trunk.

No, I don't see what you mean here.  You seem to be saying
that a branch, once made, is kept in isolation from the trunk
(or stable code branch - whatever you prefer to call it).  If
that's true, then why bother with merges at all?  Are you
saying that once a branch is created, only one merge can
be contemplated: back to the stable branch?  That would seem
to be a huge restriction that only allows CVSNT to support
one specific code development process, and makes it very hard
to keep separated development streams in sync.

> It's the only reasonable behaviour.  There's no automatic
> way  to do this and absolutely never can be since it's an 
> unsolvable problem.

We'll have to agree to disagree on this point, then.  I
simply don't see what's insoluble or even difficult about it,
so I have to conclude that we are simply misunderstanding
each other's point of view.  Yes, there are intractable
merge problems, but I don't see that this is one of them.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook