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