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 storageget 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
|