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

Tony Eva teva at Airspan.com
Wed Jun 7 11:42:15 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:
> Tony Eva wrote:
> > No - the changes in B1 are not lost.  B2 is not just a copy 
> > of A3, it is a merged sum of B1 and A3.
> No it isn't.  B2 is simply the changes required to go from B1 
> to the merged  B1+A3. Similarly B3 does not contain B2.
> It does not contain B1.  No revision ever contains a copy of 
> its ancestors - that would be a nightmare to manage (and very
> large).

I think you're looking at this from an implementation perspective.  When
I say "contains B1", I don't mean that B2 in the repository physically
contains a copy of anything.  I'm talking about the information (not the
low-level bytes) within the file, in other words a higher-level
conceptual view of the storage process.  When a user retrieves version
B2 of the file, he gets a file which is B1 changed in some way that has
made it into B2.  That's what I mean by "contains B1".

In terms of the example files in my last post, "contains" only in the sense that the information in is propagated
into  Of course it's stored as a diff, but at a higher level
you can think of as being "with modifications".

> You declare it to be equivalent to A3 in the mergepoint, but 
> if you just take that in the other direction you get a merge 
> that does not contain B1.

? What do you mean?  Merges are unidirectional.  You can't take it in
the other direction.  If I've merged A3 to B2, A3 is unaffected in any
way, it knows nothing about B2's history.  But nobody is proposing going
backwards over a merge.


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