2007/5/20, Avi Bryant <avi at dabbledb.com>:
> 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.

Hi Avi,

thank you for your answer. Do you think your suggestion can be
implemented in 3 months by someone who does not have knowledge about
MC2?

If yes, can you give me an overview of the current MC2 hierarchy? This
would help me start in good conditions and maximize the chance to have
a usable result at the end.

Google pay me to do that work so you should not think it's a waste of
time to help me begin.

-- 
Damien Cassou