Obviously we'll have bumps along the way, and a lot of facilities will
still be added to round things out and make them more comfortable for
specific modes of cooperation.

But I've never seen a change management system with a model I've really
liked, until now. Monticello's rocks.

You're actually, truly not insisting on having a Wise and Almighty
Repository, but allowing practically any collection of versions to
function as one. It is sheer audacity :-)

Daniel

Colin Putney <cputney at wiresong.ca> wrote:
> 
> 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