Motivations behind Monticello
Last updated at 1:27 am UTC on 17 January 2006
A few emails from the Squeak-dev mailing list...
On Thursday, July 24, 2003, at 11:08 AM, Julian Fitzell wrote:
> Well, to do a merge you want to find a common ancestor (preferably the
> most common one). The nice thing about a distributed repository
> system is that you can maintain your own for your company (or on your
> laptop while on the plane) but you can push them into a public
> repository later. So it may be a disadvantage to identify a version
> by URL. You certainly could provide a URL to a version, but I think
> their could be many URLs that would give you the same version
> (uniquely identified by UUID).
>
> So it's likely that a project would have a "public" repository of
> versions that have been published. Developers might have their own
> repositories and they might list each others' repositories as places
> to look for packages, but end users would likely only have the public
> repository in their lists.
>
> That's the vision we've been talking about anyway. Not that there's
> anything in the MC model that forces that particular view - that's
> just what we've been moving towards as I understand it (and I say we
> loosely since I've been talking to Avi and Colin a lot about it but
> not really contributing much code recently :).
Yup. The idea is that what we've got in Monticello right now gives us a
fairly good base for exploring ways to do distributed concurrent
development. As the intersection between the worlds of Smalltalk and
Open Source, the Squeak community is in the odd position of not being
able to use the established patterns of either tradition to organize
its self. I'm really liking the directions SqueakMap and BFAV are
taking, and I'm looking forward to seeing what we'll come up with for
source code management.
So here's some of the thinking that Avi and I (and Julian, when he has
time) have been tossing around since Monticello got started at OOPSLA
2002.
One of the key issues is the tension between declarative vs imperative
modeling of programs. The really neat thing about Smalltalk, and the
source of a lot of its power, is that it's just an environment where
objects live and interact. If you want the system to behave a certain
way, to fetch and display your email, say, you just add some objects
that behave the way you want. The fact that "it's all just objects
interacting" - the imperative model - is what makes Smalltalk such a
nice place to live and work.
The down side of the imperative model is that it's really hard to
replicate and distribute that email-reading behaviour. The very notion
of a "program" gets slippery. We can all see that Celeste is something
that we might like to use in different images and different
circumstances. To do that, we need to put a box around that email
behaviour, define it, name it. Declarative modeling is really handy for
that - in Java, for example, there's no question of where a program
begins and ends.
With Monticello, we want the best of both worlds: declarative models of
programs (or packages, really) that we can examine, compare, and relate
to various environments, without inhibiting the traditional Smalltalk
"mucking around with objects" development style.
So Monticello is organized around "snapshots" of the package. You do
your development with all the usual (or new and wonderful!) Smalltalk
tools. When you've got it to a state you like, you use Monticello to
take a snapshot. Snapshots are a declarative model of the Smalltalk
code that makes up a package. Here we throw out all the wonderful
flexibility of the object environment and insist that the package be
composed of classes and methods, organized in various ways, with
well-defined dependencies and initialization expressions.
Snapshots can be compared to produce patches, or created by the
application of a patch to a snapshot. They can be serialized and moved
between images, or stored on disk. And of course, they can be loaded
into the image - they can manipulate the object environment to restore
it to the state it was in when the snapshot was taken.
Another thing you can do with snapshots is version them, which is
another of the key issues that Avi and I have been batting around.
Versioning a program is really about recording a history of how that
program developed. To model the relationships between snapshots, you
have to model the development process. Given such a model, you can
develop tools that facilitate the process; to use them effectively you
have to follow the process they model.
As it happens, we live in interesting times. With the formation of the
Guides, we've started working our way towards a new development process
- one that doesn't revolve around Squeak Central, and that hopefully
combines the best of both the Smalltalk and Open Source worlds.
With Monticello we wanted to do two things. On the one hand, we want to
support the process that has developed so far and at the same time,
provide a platform that can be used to explore different ways of
organizing development. We don't want the tool to impose a direction on
our efforts to organize ourselves as an Open Source Smalltalk community.
This first release of Monticello provides the most elemental versioning
system we could imagine. A "version" of a package contains a snapshot
and some meta information: the author's initials, a timestamp, a
comment, and a list of versions from which this version is descended.
With this ancestry information any developer can intelligently detect
changes that another developer has made and incorporate them into his
own image.
There are certainly many more things we can do with versions, and as
our collective development style emerges, we hope we'll see new tools
and repositories which reflect it.
Colin
On Nov 14, 2003, stregone@att.net wrote:
>Hi all.
>
>I'm the Chief Architect/CTO for a software company and as I mentioned in an
>earlier post, we're starting several new projects. Some of these projects are
>using Smalltalk (the first time for us, though I've been using it at home for
>years). The reasons for switching to Smalltalk are various but mainly revolve
>around faster implementation, existing projects/libraries that implement some
>of the functionality we need, and the fact that I tired of our constantly
>breaking procedural Java code.
>
>The "problem" is this. Up until now we've used CVS for code versioning,
>sharing, and back-ups. CVS works at the "project and class" levels. Now,
>I've looked around a bit at the options available, but unfortunately I won't
>have time to try them all- so I'm hoping to benefit from the experts on this
>list.
>
>First off, do we have a best pratices page for team development on the wiki?
>We it be of use to anyone if I documented this changeover that we're making as
>a commercial software house?
>
>Secondly, it seems to me that perhaps Monticello is the closest thing to CVS
>in the sense that it also operates on the package and class levels? Whereas
>Magma, for example, operates more on the object level. Or have I
>misunderstood? I know that this may be the time for a paradigm shift (and I'm
>open to that), but the other developers have not been using Smalltalk and
>they're in for several paradigm shifts as it is.
Hi Brian,
Congratulations on your switch! A couple of years ago I was in the same position, and I'm very glad I went with Smalltalk. I'd recommend Monticello; it was designed with your situation in mind. Here are some thoughts to help you get oriented.
First, one of the design goals of Monticello was to support the same kind of concurrency that CVS allows. Members of the team should be able to work independently and merge their differing versions afterwards. As Monticello evolved, it moved further in this direction, in that it is now oriented towards distributed concurrent development. Where CVS relies on a central server with a single canonical repository, Monticello is happy to work from several different repositories at the same time. Unlike CVS you don't set up a Monticello server; Monticello can use any storage area as a repository: memory, disk, or remote machines via HTTP or FTP. This lets Monticello projects begin and grow in a more ad-hoc fashion, without any investment in shared infrastructure.
I bring this up because distributed development is very important in an open source project like Squeak, but less so in the commercial world, so it might not be immediately apparent how and why Monticello works differently than CVS.
Second, one thing that Monticello does have in common with CVS is that it operates on snapshots of your program. Unlike most Smalltalk version control systems I'm aware of, it does not integrate with the development environment. It does notice if you change a package, but that's it. You can use whatever tools you like to write your program. When you've got it the way you want it, commit that version to a repository with Monticello. Monticello is a versioning tool, not an IDE.
Finally, Monticello is still under development, and there are a lot of things still to be done. If you have any ideas on how to improve it (or code, naturally) please share them. I'll go out on a limb by speaking for the rest of the Monticello team - we view Monticello as an experiment in development practices as much as software, and we're always interested in new results.
Cheers,
Colin
