On Wed, 7 May 2003 diegogomezdeck at consultar.com wrote:

> Daniel,
>
> I lost your proposal in the "avalanche" of messages :)
>
> Actually I don't know what is exactly Monticello... Where can I read about
> it?  Avi, are you there?

Yes, I'm here, just haven't had time to respond yet.

Quick answer: Monticello is the evolution of DVS.  It includes a (fairly
simple) declarative model of Smalltalk source code.  It can produce a
Revision object from a package in the image (using DVS naming
conventions).  It can store and load these revisions to disk (in a
CVS-friendly text format).  It can check a revision for unmet dependencies
before loading it (ie, the revision has loose methods for a non-existent
class).  It can compare two of revisions and produce a patch, which
can then be loaded (allowing clean updates of packages in an image, like
DVS).  It can merge two patches, with conflict detection (and resolution)
- if they have the same ancestor, this is like a CVS 3-way diff.

At one point it included a simple remote repository system (for
maintaining a bunch of revisions on a server, and updating to the most
recent one), but I dropped that for now and instead use CVS to manage the
serialized revisions.  When the client side is a little better developed,
I'll bring back a Squeak-based server.

I wouldn't say it's immediately useful for what Daniel's proposing - the
main problem is that it assumes all changes *can* be expressed
declaratively, and I have a feeling that KCP and MCP changesets anyway are
going to have some DoIts rather than just method and class modifications
(but maybe that's not true?).  However I am definitely willing to do what
I can to make it work, if we can figure out exactly what's needed.

> > Hmm, we already have the start of a change management system, maybe
> > this can be it's first UI.
> >
> > - make something listen to the list [could be based on the existing
> > bug-fixes archive by BertF],
> > - add each changeset as a Monticello package with the rest of the
> > message text as a comment on those.
> > - Enable the remote repository access stuff enough that people can
> > "get" stuff.
> > - A simple specialized UI that gets bunches of updates the monticello
> > repository.
> > - For the rest of the review tool, use OSProcess to open a clean image
> > with the chosen set of changesets loaded.
> >
> > Avi, what will it take for the Monticello side of this? can you do it?
> > *************
> >
> > Daniel
> >
> > diegogomezdeck at consultar.com wrote:
> >> Tim and list,
> >>
> >> > <diegogomezdeck at consultar.com> wrote:
> >> >
> >> >> Let's talk about wich tools we need to make the process smooth. I
> >> >> offer to program it.
> >> > Good man!
> >> >>
> >> >> Initial set of features:
> >> >> - publish a changeset to the "repository"
> >> > I think this is partially covered already; by mailing a changeset to
> >> > the list the sqfixes filter already grabs it and 'all we need' is a
> >> > way to treat the results as a convenient repository. I'd claim that
> >> > the current format is not too convenient because you get huge lists
> >> > and little navigation support to help one find any interesting or
> >> > relevent entries. My theory is that we can do better and that
> >> > possibly using the FTP access already available would be good.
> >> > Another possibility that has just occured to me is that a variation
> >> > of SM would have some virtues. Instead of simply installing any
> >> > change (danger!) it would fetch the whole bundle of messages and
> >> > changes associated with a bug/fix/enh.
> >>
> >> I was thinking about using a swiki page.  This page is *only* changed
> >> from squeak.  In this way we can continue working in a similar way
> >> that MCP/KCP but much more automatized.
> >>
> >> The squeak will parse and modify the page based on the features we're
> >> talking about (changeset, comments to it, fixes to it, etc)
> >>
> >> What about that?
> >>
> >> Will the HTTP and the HTML stuff removed from the base-image?
> >>
> >> Diego
>
>
>
>
>