[V3dot10] Re: Monticello and 3.10

[Keith Hodges]

>> What is a .mcm file?
>>     
>
> A Monticello Configuration Map.
>
>   
>> Is that something that should be loadable with
>> the Monticello that comes with 3.10?
>>     
>
> Yes.
>
> Cheers
> Philippe
> _______________________________________________
>   
Ok, so I thought I would just check what I thought was the case. In 3.10 
I open Monticello browser in the MagmaTester repository and... it doesnt 
even see the mcm files.

The monticello configuration's browser is for writing configurations, 
but I see no ui for loading one in from a repository. Am I missing 
something obvious.

Monticello1.5 can see mcm's if MonticelloConfigurations-kph.44 is loaded 
and can load them via the Load button.

The Monticello15 bootstrap is simply the same code via a file in. This 
is the only reliable way of installing one version of MC on top of 
another unless effort has been made such that the version being loaded 
in doesnt break the loading process as run by the version being 
replaced. However it is impossible to do this for the 3.10 version since 
it has particular differences.

My personal thought is that whatever testing is needed on 1.5 needs to 
be done, and it should be included in the base 3.10 from the beginning. 
Anything less is a recipe for confusion. I think it has to be this way 
because my 1.5 is  one of only two viable ways forward for the 
Monticello1 genre. The other being for someone else to repeat all the 
work that I have already done using the 3.10 as a base. Incidentally 
That is what I did, I started with the version in 3.10, but found that 
Ralphs 'atomic loading' additions to md-308 were superfluous.

MC15 Sales pitch;

Imagine this, you are using someone-elses package say, seaside, and you 
change a method in seaside because it doesnt quite do what you want it 
to do. Then a few days later a new update for seaside is released so you 
load it. What happens to your version of that method.

A. Its overwritten by the updated package's (seaside's) version of that 
method, so when you commit your package to its repo it looses a method.
B. Your version stays, the updated packages' version is lost if you 
happen to commit an update back to the seaside repo.
C. It loads the seasides's version, then it loads your version again (so 
the seaside version is preserved in the version history as the one 
before yours) Saving the seaside package spots the override and saves 
the previous seaside version of the method. Saving you package saves 
your override. The integrity of both packages is preserved.

When this works I think it is really worth having

Keith