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

Tony Eva teva at Airspan.com
Mon Jun 5 16:12:49 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:
> But you have not said that b1 contains HEAD - in fact they
> may be very different.

When I gave the command 'cvs -j HEAD c.c' to merge HEAD to b1, I
said to CVS that b1 will now contain HEAD.  That's what a merge
is, surely - the incorporation of the information from one branch
into another.  Indeed, that's what mergepoints are for: explicitly
to recognise the fact that once a merge has taken place, that
merge must not be repeated because the information has now been
included in the merge recipient.

> It doesn't - it needs to take into account all changes in B
> that happened *before* the merge too.

The result of the merge is a file (on B) that has all of B's changes
up to the merge, and all of A's changes from the branch point up to
the merge.  Assuming no other changes on A or B, a merge from B->A
is just a copy because all of the information from A and B are in
the head of B.  There is no other information that isn't there.

> If you [do] bidirectional merges you don't have a proper
> changeset since you haven't clearly separated the changes.

Maybe 'changeset' was the wrong term, and maybe also we're running
into confliciting views about how we anticipate that CVS would be
used.  This is how I see it:

If a developer is responsible for implementing a feature of some
complexity, the coding/testing may take some time.  It would be
reasonable for them to want to save their intermediate work into
the repository from time to time, to guard against accidental loss
of their working copy; so they would wish to perform occasional
commits of unstable (or even non-functional) code.  They cannot
commit this to a stable HEAD, and so will instead create a private
branch and commit to that.  Since the feature takes some time to
code and test, HEAD will move on, and they will wish to keep their
private branch up to date with regular merges from it.  Finally,
they will make the last couple of changes, do a final merge from
HEAD to pick up the last few updates, run their last test, and
then commit for the last time to their private branch.

Now the feature is complete and stable, it can be included into
HEAD.  That's where the "bidirectional" merge comes in (and, in
my view, comes unstuck).

> Normally this wouldn't be handled by branches at all - you'd
> do it using the builtin support using bug IDs or by either
> cooperative or reserved edits.

I may well be trying to use branches for something other than
their intended purpose, and maybe bugids will do what I want.
I will look into that in more detail.

However CVS *does* support the ability to put individual files on
a branch, not the whole repository, and it is a legitimate use
of the branching capability (IMHO) to allow a set of files to be
collected together as I outlined.

I still believe that the CVSNT behaviour under the bi-directional
merge scenario is counter-intuitive, and I struggle to see how
it can be regarded as correct.

Sorry if I'm banging on about this too much, and I appreciate the
responses so far - I am just having some difficulty working out
if it's possible to use CVS to support the development model I
need.  If not, so be it, though I can't see that what I'm
proposing is particularly weird, so I feel there must be a way
of doing it.


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