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

Tony Eva teva at Airspan.com
Mon Jun 5 14:12:43 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.

Thanks for the quick reply.  As I understand it, then, I'm not doing
anything fundamentally wrong, it's just a scenario that isn't really
supported by CVS.

Tony Hoyle wrote:
> Tony Eva wrote:
> > I would *expect* this to use the mergepoints to recognise that b1 
> > already contains all of HEAD's changes from 1.3 to 1.5, and thus
> > HEAD 1.5 is now the common ancestor.  In fact, if HEAD has not had
> > more commits since 1.5, this "merge" should just be a trivial copy
> > across to HEAD.
> It's impossible to know that - you might have discarded the merges,
> new, conflicting ones, etc.

Yes - but I don't see how that's relevant. I would contend that when I
commit after the merge from HEAD to b1, I have effectively declared that
b1 now contains the merged results to my satisfaction.  CVS should take
my word for it and regard the merge from HEAD to b1 as complete.  (In
fact, I may even have overridden the results of the merge with an
entirely new file, if I felt like it - that's my business, not CVSs.)

> Merge A->B does *not* imply a merge B->A since B will contain
> that is not in A.

I agree.  However, after a merge A->B, B contains a combination of
information from A and information from B, and by committing the merge,
I declare that I am happy with the results.  At this point CVS should
assume that B has all of A's information *up to the point of the merge*,
and that a subsequent merge B->A only needs to take into account any
changes on A and B that happened after the merge.  If there were none
(as my original scenario had it) then the merge is in fact simply a
transfer of information from B to A - i.e., just a copy.

> Some versions of cvsnt did this and it was removed after a scenario
> occurred where people lost changes (luckily only minor ones).

It's hard to see how changes could be lost, assuming that all files has
been committed prior to the merge?  Of course, if someone was so daring
as to perform a merge on top of *uncommitted* changes, then they really
should have known better :-)

Also, as a matter of interest, do you know which versions handled the
merge in the way I described? It may be helpful for us to consider
looking at earlier versions, as an option for solving our problem.

> Bidirectional merging is not that common - normally you merge in one
> direction - eg. development->test->production, or stable->unstable.

I think possibly some confusion may be arising here.  I am considering a
scenario where only a small subset of the files in the repository are
being branched, not the whole thing - in other words, the branch is a
changeset.  If you are considering a branch to be a split of the entire
repository then I'd agree that merging would typically be unidirectional
- in the changeset scenario, however, bidirectional merges are the norm.
Might it not be a good idea for CVS to support this type of branch usage
through - say - another command, or another update option?

Thanks again for the response.


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