[ANN] Monticello Versioning
cputney at wiresong.ca
Thu Jul 24 23:48:38 UTC 2003
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
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
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.
More information about the Squeak-dev