Avi Bryant wrote:

>
> On May 24, 2004, at 1:58 AM, goran.krampe at bluefish.se wrote:
>
>> And another thing - we have been talking about having Monticello
>> included in Basic. I think that would be good.
>> Monticello is a major important piece of the whole "packages" thing, we
>> have discussed it earlier too.
>>
>> Avi?
>
>
> As I say, it's fine with me.  Last time this came up there was a 
> concern that we not make other key parts of the image dependent on 
> Monticello, which I completely agree with - the Browser, for example, 
> should be version-control agnostic.  Given that, hopefully it's ok 
> with everyone.
>
> Maybe we can tentatively plan to include in in 3.8a, and see if anyone 
> objects.


Sounds okay to me.  I've only used Monticello a bit, so I'd want to be 
clear on what exactly this includes... (bear with me if some of my 
understanding is incorrect)

- Having a good alternative to changesets for tracking chunks of code in 
a purely declarative way (including class extensions etc.) is definitely 
good, although I guess we already have that with PackageInfo.

- Being able to have version numbers associated with these chunks of 
code is also a good thing.  I don't think we have that with PackageInfo, 
but we would with Monticello?  For example, if we carve out the 
ProcessBrowser in Basic as a PI package, the image could know that in 
3.8alpha-6124, the ProcessBrowser package is mc version 1.23.  (Perhaps 
there is an overlap with the concept of SM versions.)  But the useful 
thing would be that we could determine the diffs from ProcessBrowser 
package 1.21 and 1.23 from the image, which we cannot really do with 
changesets.  Would this require connecting to a server which has the 
entire ProcessBrowser package history, or would this history be 
contained in the image itself, as it is with changesets?  (At least the 
history that actually came through the image via updates.)

- Having the Monticello client code in Basic seems useful, too... being 
able to connect to something like SqueakSource easily.

- Does this also include Monticello server code?  Kind of like how the 
SqueakMap package has both the SM client and SM server code.  Er, ok, 
reading the Monticello description it looks like it does not, so 
nevermind.  (It looks like SqueakSource is a special Monticello 
repository server app.)

You mention that things like Browser should be version-control 
agnostic... I agree, I think we should be prevent inappropriate 
dependencies like that.  Actually, Browser should not be dependent on 
Changesets either, which is a similar concept (although I wouldn't be 
surprised if there are some inappropriate dependencies there).  Any 
Monticello-related addons to the Browser could be done via proper class 
extensions contained in the Monticello package.

- Doug