Monticello and live systems (was Re: 1 day left...)

Alan Lovejoy squeak-dev.sourcery at forum-mail.net
Sun Feb 26 09:02:05 UTC 2006



Avi said:
"It's a hard problem in general, but dealing properly with class renames
isn't all that hard - we just need to track classes by some kind of unique
ID (which we assign the first time we see them and maintain from then on)
rather than by name.  This would be a very shallow change to MC, and even
making it backwards compatible shouldn't be *that* hard."

Harmony, the module/versioning tool I developed about ten years ago, did
exactly that: it tracked classes, Modules, Subsystems and Systems by GUID (a
System is roughly analogous to an Envy config map--it specified the complete
set of classes and methods that would be resident in the image.)

Harmony could also export either "absolute" or "relative" versions of
modules (or subsystems, or systems.)  The "relative" exports were somewhat
like changesets, except that they were generated by version difference
computations.

Harmony permitted the same methods and class definitions to reside in any
number of modules, the same modules to reside in any number of Subsystems,
and the same Subsystesm to reside in any number of Systems. An extension
method was simply any method in a module in which the method's class
definition did not reside.  Version conflicts were won by whichever module
got loaded last--but the losing modules would be marked as changed.
Conflicts were only possible when loading modules a la carte, instead of as
part of a containing Subsystem or System.

Harmony, unlike Envy, neither required nor used a central server. It was
designed to allow team members to work "offline," and enable them to merge
their work with that of others whenever convenient.

What Harmony didn't do was provide any namespace support. I now realize that
that was a big mistake (another big mistake was not providing very much
documentation.) In fact, were I to attempt such a project again, there's a
variety of things I would do differently, although there would proably be
some resemblance to the feature set I describe above.

Craig Latta's Naiad system is also based on GUIDs.  Craig and I had many
discussions about the architecture and design of Harmony a decade ago.

When you combine Namespaces with GUIDs, you get a synergistic effect that is
better and more powerful than the sum of its parts.  The effect is to give
classes and modules a kind of "object identity" AT DESIGN/CODE TIME that is
persistable and transportable across address spaces. This is a key,
fundamental benefit of the Naiad/Spoon architecture.  Go Craig!

--Alan





More information about the Squeak-dev mailing list