On Wed, 23 Jul 2003, Julian Fitzell wrote:

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

We're talking at cross purposes here.

The thread started because Daniel wanted a way to send us something
smaller than the 200k version he had produced.

My suggestion to solve that is to be able to represent a version as a base
version ID + a patch against that base version.  This object would have
the exact same semantics as a full version file out, but would happen to
take up a lot less space.

So Daniel would still be sending as a "full" version, it would just be 2k
instead of 200k.  As you say, within the system full versions (or things
that act like full versions) are what we should be sending around.

Now, it is indeed useful to be able to produce a changeset for use outside
the system, and I think we agree about how that should work and what it
should or shouldn't be used for, but that's a completely separate issue.

Avi