Avi Bryant wrote:
> On Wed, 23 Jul 2003, Julian Fitzell wrote:
> 
> 
>>I don't think MC needs a custom patch format.  Changesets are perfect
>>non-declarative patch files already.  It would be nice to include the
>>version they were made against (or between) in a comment at the
>>beginning or something, just so you can go back and look at it if you
>>like.  But I don't think it's actually of much use to MC because the
>>file format is non-declaritive, so it won't be able to look for
>>conflicts, etc. anyway.
> 
> 
> Well, MC already has Patch objects that it uses internally.  What I was
> picturing was a subclass of Version that stored a Patch instead of a
> complete Snapshot.  As long as you had the base version accessible, you
> could treat this just like any other Version - when you sent it #snapshot
> it would just pull in the base version and apply the patch, then hand you
> back the reconstructed Snapshot.  It's a space/bandwidth optimization,
> which is the main reason people use patches, and I think is what Daniel
> was asking for.

Erm... why does it need to be a version?  And again, I think the 
changeset is useful when you get *outside* the system, not when you're 
inside it.

> You convered the second reason people use patches, and I think you're
> right that it should be handled through merging.  I haven't tried to work
> through your four-way merge example yet but I don't see why we couldn't
> hack support for that in... (lazy question: can a four-way merge be
> modelled as three two-way merges?)

I assume you mean 2 three-way merges?  a 2-way merge is just a 
replacement :)

Hmm... I'm drawing it out and I think, at least in the simple case, you 
can do it as a single three-way merge by reparenting one of the versions 
so it looks like a three-way.  But what I can't quite remember is 
exactly what cases that breaks down in and I don't have time to stare at 
it anymore.

My memory is that the 4-way merge involves a process of rewriting 
changes in a patch  to avoid conflicts based on the 4th node.  But it 
may be that the combination of not having an order-based version format 
(ie. text file) and storing history of a version resolves the issue 
satisfactorily.  One of us will have to dig out the 4-way merge paper 
again (though at the moment I can't even find it on google... sigh)

Julian