Monticello 2 - request for information

J J azreal1977 at hotmail.com
Fri May 18 13:22:00 UTC 2007


Any interest in making a separate list or something for MC 2 discussion?  I 
have several things I would like to see happen with it and would be prepared 
(interested in fact) to contribute time on the project.

The main goal I have for it is that the the system should use change sets as 
the base unit and in fact push more functionality down into change sets, and 
change set tools.  I have heard that their are bugs with change sets but 
that seems like a reason to fix the bugs, not avoid the use of change sets.

Some of the benefits of a change set based approach are:
Presumably faster load/save times since much less of the system must be 
checked
Don't have to play funny tricks with protocols to get changes included in 
your packages
Easier to differentiate local changes from package changes (see below [1])
Easier to separate major revisions after the fact (see below also [2] :)

[1] This is something I am dealing with now:  I am finishing up on adding 
recurrence rules to the ICal package, but I switched to 3.10 because I 
wanted to use the latest of Damien's dev images.  The problem is one of the 
classes in ICal calls #raiseSignal: which doesn't seem to work in 3.10 for 
some reason.  So to get my tests to pass (or at least test *my* code :) I 
just changed the #raiseSignal: call to use #signal:.

But this isn't part of the work I am doing, and shouldn't be part of the 
changes I upload.  In change sets, it is easy, I just create a new change 
set and push the unrelated methods into it.  If MC (2) used change sets then 
I could just tell the system that that set isn't part of my RR package.  
Then I can forget about it, and just do my saves, knowing that MC wont look 
at that set.  The way it is now, I have to revert that method for every 
check in.

The other option for me atm would be to just publish it with one of my other 
changes, but then it is buried deep down in an unrelated change (similar to 
how expensive and useless bridges sometimes get built in the US).

[2] And speaking of keeping related changes together, it is nice to be able 
to do this after the fact.  One of the things I really like about darcs is; 
I can go through coding, make as many changes as I want but then when I 
commit them I specify which changes go in what change sets so that they can 
be grouped in some logical way.  This makes it a lot easier if a person 
wants to add one set of changes, but not some other.

Change sets have this ability right now, but no collaboration tool (afaik) 
to manage the change sets themselves, once grouped.

Anyway, I would like to discuss this and more so I hope there is interest in 
setting up a list or something.

Thanks,
Jason

>From: "Damien Cassou" <damien.cassou at gmail.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev at lists.squeakfoundation.org>
>Subject: Monticello 2 - request for information
>Date: Fri, 18 May 2007 13:20:08 +0200
>
>Hi Avi and Colin,
>
>Google will pay me during this summer for a work on packages and
>Squeak. I would really like to work on Monticello 2. My aim is that in
>September, people will be able to start using it. But do to that, I
>need some cooperation from you. Can you please answer my questions?
>
>Where can I find documentation about what you have done?
>
>What are the most important hierarchies? What are their roles?
>
>What is the semantic behind the categories MC2-Squeak, MC2-SqueakPlatform?
>
>What is the status of MC2? What has been done and what needs to be done?
>
>
>Thank you very much
>
>--
>Damien Cassou
>

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507




More information about the Squeak-dev mailing list