[V3dot10] needed tool
milan.zimmermann at sympatico.ca
Mon Jan 22 03:32:22 UTC 2007
On 2007 January 21 09:31, Ralph Johnson wrote:
> Markus said that one of the big problems during harvesting is that
> when you read change sets into your image, some of the methods get put
> into unexpected MC packages, and the harvester doesn't save those
> packages and so loses the code.
Experiences Squeakers, let me understand this problem some more. I understand
how a changeset can contain code that "belongs" to several Monticello
Packages. What I do not know is how much code is currently maintained in
Monticello vs Changesets. Let me analyse this further: I looked at 3
SqueakMap projects. One is maintained my PR, another by a CS, last one by
MCZ - here
So as far as code on SqueakMap, it is a mixture. Another question is: Of the
current 3.9 image, are there any parts maintained by Monticello? For example,
if I want to change something in Collections (and I mean this purely as
example, my question is about all the 3.9 image code): is there a MCZ for
Collections, or do I have to make my change, and, if I want to share it,
create a CS?
I am trying to understand how to relieve the 3.9 harvesting problem Ralph
described above from Markus. (more notes below)
> A change set might have code that goes in several packages. There
> ought to be a way to see all the packages that are influenced by a
> change set. I don't know of any tool that does this. Is there one?
I do not know, but I am trying to think how one would write such tool. First,
what is the code "managed" by one Monticello package, is fairly simple to
define: Let's say there is a Monticello Package named ABC. This Abc Package
manages (simplifying, just to clarify the point):
- all classes in system categories with names starting with "Abc".
- all method with method category names starting with "*abc".
- all methods in classes that are in system category starting with "Abc"
So it seems that if the tool would look into the changeset, look what are the
categories, class and method names contained there, and applies those rules,
it should be able to generate a list of Monticello packages which the CS
_potentially_ affects. The reason I am saying _Potentially_, is because such
Monticello package may not even exist. So it seems on top of the logic I
think should be doable, there needs to be a "global" Squeak list of
Monticello packages in existence, and the tool would intersect the result of
it's step1 automatic analysis with this "global list".
Does this make any sense at all....
> Class ChangeSet should be changed to indicate the MC packages that it
> uses. Also, the change sorter should display the packages, and let
> you save them. Ideally, you could save to all the MC packages at
> once, and merging would be atomic, and you could use the same comment
> for all updates. But first, someone should hack ChangeSet to indicate
> the packages it is influencing. Do I have a volunteer?
First I revert to wait state as maybe such tool exists already and someone
will reply :)
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10