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

Tony Hoyle tony.hoyle at march-hare.com
Wed Jun 7 12:59:32 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.

Andreas Krey wrote:
> Somehow I should really have used revision numbers instead of An and Bn
> to make absolutely clear that these are committed revisions, not some
> diffs.

Full revisions only exist in the sandbox - when you're talking about 
revisions in the repository it's important to remember that cvs (and all 
version control systems AFAIK) work with diffs exclusively.

Merging would be impossible if you didn't work like that - you wouldn't 
be able to isolate changes and apply them in the right order.

> B2 ist the *result* of the merge of B1 and A3, thus all changes
> on the way A1->(B0)->B1 *and* all changes on the way A1->A2->A3
> are present in the revision B2, plus what was needed to resolve
> conflicts.

No, B2 is just the changes required to incorporate A3 into the branch. 
B2 does not include any part of B1 unless the merge requires a change to 
B1 to work.

>>You declare it to be equivalent to A3 in the mergepoint,
> No. The mergepoint declares that B2 is the result of the
> merge of A3 and B1. A3 and B2 differ by everything that
> has been done on the branch before, they are *not* equivalent

 From cvs' point of view they are equivalent.. an alternative way of 
viewing a mergepoint is a point of equivalence in the tree - it's a 
point that you don't have to worry about earlier revisions so can 
simplify the merge.

Trust me - I invented the things :)

You can also think of it as moving the branchpoint, but that gets 
ambiguous, and doesn't really describe what's going on.


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