Some thoughts
> The future , as Goran said on Supertool, is not Monticello.
> Monticello is good for some, but is not the silver bullet.
>
>   
I dont agree with this SuperTool is the future approach, having lived 
with MC2 is the future for all too long.

It has taken years for the use cases to form around the current tools 
and some of these are non trivial. I expect any new tool will do the 
easy stuff and fail to do the difficult stuff and we will be back where 
we started. It takes a lot of effort and "going around the loop"  to dot 
all the i's and cross all the t's. So I think we would be better off 
actually finishing one tool (MC) or even its successor (MC2) before 
starting on another.

For example the case where you want to maintain several versions of the 
one method in the image:

You want the original method to stay with its original package so that 
when you save the original package that package does not get broken. You 
want your changes to stay with your package so that that does not get 
broken. This is not as easy as it sounds.

A second example, however you do it,  the out-of-order loading supported 
by MC1.5 requires a cache of not-yet-loadable elements, I call this the 
orphanage. Orphans get rehomed once the parents arrive!

So whatever tool you come up with will have the same basic elements, 
like MC1 has MCMethodDefinition MCClassDefinition 
MCClassVariableDefinition etc and a loader to apply them, browsers to 
look at them, differs to compare them etc. Why have 1 technology when 
you can have 4. (MC MC2 SuperTool and SystemEditor)

I mention SystemEditor because I think that a persisted system editor 
would make a useful binary package distribution format which only needs 
SystemEditor to atomically load!

MC supports Diffs in theory, so the "packages are too big" argument can 
be tackled.

I started to add changset support to MC1.5 as well. This makes sense 
because MC already has browsers for all this stuff.

By all means improve the recent changes and change sets support, this 
will help all tools to work better. But is the changeset functionality 
not wired in a deep way in all of the forks that this is aiming to 
support? Migrating everyone to this new scheme is not going to be easy.

Personally I think that MC1.5 with SystemEditor working (MC1.5 is ready 
its SystemEditor that is not trested) would be a winning combination. I 
also think that MC can be simplified and slimmed down a lot with 
SystemEditor support working.

I am disappointed that we are unable to raise the effort to get 
SystemEditor tested and usable. This is a bottleneck for all the 
initiatives which want to use it MC1.5 MC2. and Supertool, so I think it 
should be THE priority task. (I am a bit snowed under for now myself)

sorry for being overly cynical

Keith





> I wish some could help me for not having Monticello in the base image.
> Only we need a "Monticello loader" and people could load Ralph version, Avi
> version, Impara version, Keith version .
>
> Or none of this in a year from today when Supertool is builded and adopted.
>
> Edgar
>
>
>
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
>
>