Below are a few posts I made the Squeak-dev mailing list concerning the philosphy behind Monticello - the development process we envison for Squeak projects and the way Monticello supports it. Some of the posts have been edited slightly to remove material that doesn't make sense out of context. The originals can be found in the Squeak-Dev Archives.
-Colin Putney
From: Colin Putney Date: July 24, 2003 6:48:38 PM EST
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.
From: Colin Putney Date: August 1, 2003 11:45:08 PM EST
On Friday, August 1, 2003, at 07:00 PM, Derek Brans wrote:
I'm floundering a bit in understanding Monticello.
I want to have an "always online" server hosting a repository where my code can be found. I have the server, which has up until now hosted my CVS repository.
How does one setup a Remote Monticello Repository?
The discussion around MC seems to say that we are done with centralized repositories. What is meant by this? Isn't it handy to have one repository to manage code, so it doesn't start branching in 8 directions?
Are we talking about a community of developers working and intermittingly merging? How is that different than the cvs model?
Well, I don't know that central repositories are a thing of the past, but it's nice that we don't have to do it that way. We definitely do want to support that "community of developers working separately and intermittently merging" model since that's how most Squeak development seems to work.
CVS does a good job of allowing developers to work concurrently, but it doesn't handle distributed and disconnected development very well. If you're cut off from the net, there's not a lot you can do with CVS. Maintaining a local mirror of a CVS repository is possible, but difficult. Moving versions between CVS repositories is damn near impossible.
By de-emphasizing repositories, Monticello gives us a lot more flexibility. Pretty much any collection of versions can be considered a repository and Monticello will make a best-effort-with-available-information if you don't have the complete history of a package all in one place.
Frankly, I'm not sure what the development model for working with Monticello will be. What we've got now is just a flexible base for building more elaborate tools.
From: Colin Putney Date: September 21, 2003 9:33:02 PM EST
We all agree that distribution is good, but we haven't talked much about what it is that we want to distribute. I haven't quite pinned it down myself, but I think the most important thing to distribute is authority.
I really like the fact that I can download Seaside from SqueakMap, make some changes, commit to my own repository and share that with the world. I don't have to get commit rights to the canonical Seaside repository and my version is just as accessible to other users or developers as Avi's. If Avi releases a new version, and some third developer wants to merge my work into that, he can do it easily, with all history information intact. You just can't do that with CVS, SVN or any other system I know of.
Central to this is our idea that a repository is just a collection of versions, nothing more. Versions can move between repositories, repositories can be merged or divided, repositories can be moved from on url to another. There is no canonical home for a package or even a version. To put it another way, I'd like to see the MonticelloSphere evolve into something more like Freenet than the web. A particular version might be located in more than one repository, and would have a tendency to migrate to the repositories near the users that use them the most.
From: Colin Putney Date: November 14, 2003 3:16:44 PM EST
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.