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