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, 1.1.2.2 "contains" 1.1.2.1 only in the sense that the information in 1.1.2.1 is propagated into 1.1.2.2. Of course it's stored as a diff, but at a higher level you can think of 1.1.2.2 as being 1.1.2.1 "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. -- Tony