On 5/20/07, J J <azreal1977 at hotmail.com> wrote:
> I happened on something by accident today that I didn't know about before:
>
> http://www.wiresong.ca/air/articles/category/monticello
>
> >From this it sounds like Monticello 2 is quite far, in fact it sounds like
> it may even be close to ready to replace MC 1 already.

MC2 tried a lot of new things, which are at different degrees of
completion and usefulness.  Here's my take on them.

The basic underlying semantic model - storing sets of ancestors for
each method version rather than a tree for each package version - is
well developed, solidly implemented, and much more scalable than the
MC1 approach.  The key advantage, I would say, is that it allows
cherry picking individual methods when merging without causing
problems further down the line.  It also doesn't share MC's
performance problems when you get into the thousands of ancestor
versions.  So, new ancestry model: in good shape, and definitely a
good thing.

The new ancestry model also allows a new repository model, where you
commit and request individual method versions separately rather than
entire package versions.  This should have benefits for low bandwidth
connections, because the total amount of data transferred is
potentially much less.  However, it leads to a much chattier protocol,
which makes it infeasible to use the HTTP and FTP repositories we use
for MC1, or even the FileDirectory repositiories, because creating and
transferring that many tiny files is too slow.  Although we've
experimented with using things like PostgreSQL as the repository, I
think in practice we'd want a custom server written in Smalltalk and a
custom protocol, probably using the binary serialization format
defined in MC2.  New repository model: harder to deploy, probably a
good thing anyway, but needs a lot of work.

It also allows a new distribution model, which isn't tied to packages
in the PackageInfo sense.  That is, you don't have to bundle up
changes in package units - you could in theory use any arbitrary way
of "slicing" the image, and mix and match these at will (so you could
merge a version that covered all of the Squeak Kernel with one that
covered only Collections with one that covered only the
implementations of #do:, for example).  This is appealing in theory,
but it makes managing the metadata for these bundles very difficult:
the scope and ancestry of things like commit logs, branch names, and
version numbers becomes  much fuzzier.  So far, I'd be inclined to
call the Slice aspect of MC2 a useful but failed experiment, and go
back to the assumption that all changes will be bundled in
package-sized units.

Finally, and orthogonally to the rest of this, MC2 did a lot of work
to allow it to be more portable across Smalltalk dialects.  So, there
are very few assumptions made about exactly what data makes up a
method and a class and so on (does a class have a namespace? pool
variables? a category? etc), how this data gets compiled into an
artifact in the image, and how it gets retrieved from the image later.
 This leads to a lot of indirection and a lot of complicated class
hierarchies because of the need to separate the portable interfaces
from the Squeak-specific implementations.  I think the interesting
data point here is the recent port GemStone did of MC1 - on the one
hand, it's an obvious demonstration of how important cross dialect
portability is, but on the other hand, it's possibly also a
demonstration that MC2's elaborate portability scheme is overkill.  I
haven't looked into it deeply enough to know which side it argues for,
so I'm reserving judgement.

Personally, what I think I'd be most interested in seeing going
forward would be something that used the core ancestry model and
possibly portability model from MC2, but provided an MC1-workalike UI,
packaging model, and repository model.  Beyond just the technical
issues, that's what I think would stand the best chance of surviving
socially.

Avi