Another thing that bugged me slightly, which is important, IMO, when
start to use new packages. I loaded Monticello. Started playing, patched
it. Then it occured to me to send out and manage my patch using
Monticello, so I declared the Monticello package. Unfortunately, by this
time, I had lost the ability to generate the initial declarative patch,
which I would have, if I'd remembered to do this initially. This is
annoying, because then I cant see the differences, to review that all my
changes got in (no forgotten class extensions).

I could probably find somewhere public an mcv file that had what I need,
but that's a hassle.

What's one to do? when an mcv package is installed, or first modified in
the image, it should automatically appear in the workingCopy browser,
and a pristine copy saved in the repository. This gives anyone that
installed the package an official release to reference.

If MC already does this, then my only complaint is that Monticello (and
every other package) should be packaged using Monticello ;-)

What is the state of the current Monticello as a deployment format? with
regards to a minimal installer package to be included with SM and such.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> 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