[V3dot10] needed tool

Milan Zimmermann 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

http://map.squeak.org/package/051adbb6-4b9c-41e2-88b0-5fa976625a1d/autoversion/1
http://map.squeak.org/package/e29b590b-104d-476c-8497-c6068e757374/autoversion/1
http://map.squeak.org/package/80b86d52-14ea-4777-93bc-f73264ce8c8d/autoversion/2

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 :)

Milan

>
> -Ralph
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10


More information about the V3dot10 mailing list