2007/3/7, Ron Teitelbaum Ron@usmedrec.com:

http://bugs.impara.de/view.php?id=5217

If you load the fix then configurations will work.

For me configurations are an essential part of using Monticello. I know people are using Monticello without configurations but I really don't know how or why.

With Monticello Configurations you can, add multiple repositories, and packages. Then with one click you can update all of your packages from all the connected repositories to get the latest versions. Then with one click you can load all the code from all the repositories.

It is also very useful if you need to load packages in a particular order. We developed a Config file for Cryptography because some of the packages use other packages during load.

What I do everyday is browse the configuration file for my application. Then I update from repositories, and load. Every now and then I add a new package. Like I just created a Q2 package for the Q2 log of Gjallar. When I do this I'll update from repositories add my new packages and store the new config file to my repository.

Feel free to ask questions,

I loaded the fixes and commited:

http://www.squeaksource.com/DynamicProtocols/DynamicProtocols.mcm

Then, I opened a new image, loaded the fixes again, and now ? How can I load DynamicProtocols and its dependency ? I tried with MC and MCC but failed.

Thank you for your help

Hi J J,

I'm sorry but I haven't had time to look at Universes yet. Maybe someone that uses both can answer.

Ron

From: J J This must be the MC Steph was talking about. What is the difference between this and Universes? Universes require you to manually say what is the next version and MC Configs just pick the newest of everything?

...

From: "Ron Teitelbaum" Ron@USMedRec.com Reply-To: Ron@USMedRec.com, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: How-to Monticello Configuration Date: Wed, 7 Mar 2007 10:39:41 -0500

http://bugs.impara.de/view.php?id=5217

If you load the fix then configurations will work.

For me configurations are an essential part of using Monticello. I know people are using Monticello without configurations but I really don't

know

...

how or why.

With Monticello Configurations you can, add multiple repositories, and packages. Then with one click you can update all of your packages from

all

...

the connected repositories to get the latest versions. Then with one

click

...

you can load all the code from all the repositories.

It is also very useful if you need to load packages in a particular

order.

...

We developed a Config file for Cryptography because some of the packages use other packages during load.

What I do everyday is browse the configuration file for my application. Then I update from repositories, and load. Every now and then I add a

new

...

package. Like I just created a Q2 package for the Q2 log of Gjallar.

When

...

I do this I'll update from repositories add my new packages and store the new config file to my repository.

Feel free to ask questions,

Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Squeak Cryptography Team Leader

...

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-

dev-

...

...

bounces@lists.squeakfoundation.org] On Behalf Of Damien Cassou Sent: Wednesday, March 07, 2007 9:32 AM To: The general-purpose Squeak developers list Subject: How-to Monticello Configuration

Hi,

I would like to understand what are MC configurations, how to use them and why, when I try to load one, I get a:

MCMcmReader(MCVersionReader): My subclass should have overridden #loadVersionInfo

See HtmlReport: http://www.enseirb.fr/~cassou/mcconfiguration/

-- Damien Cassou

---

Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

I may have asked this before, and if so I apologize, but is there any place that shows the different packaging systems, what they have in common, what is different, etc.?

I think it is important to either make these things compatible with each other or consider adopting just one. Everyone likes choices, but for system/environment components they can be more problem then benefit.

We don't want to do like Linux with way too many choices for things that don't matter that much (e.g. 23412341234 different window managers) but completely missing seemingly low hanging fruit (e.g. not a single free installer I am aware of that can automatically set up my new Linux machine to authenticate via LDAP they way windows does out of the box).

From: Bert Freudenberg bert@freudenbergs.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: How-to Monticello Configuration Date: Fri, 9 Mar 2007 18:08:33 +0100

On Mar 9, 2007, at 16:56 , J J wrote:

...

MC Configs just pick the newest of everything?

There seems to be a misconception about MCConfigs here.

Each MCConfiguration specifies a *fixed* set of MC versions identified by version name and UUID, which is loaded.

*Additionally*, provided your repository organization and naming method follows a certain scheme, you can update the MCConfiguration automatically by using the highest-numbered package version found. This "updating" of the config does not actually install anything, it just enlists new versions. This configuration then can be loaded just like a manually constructed configuration.

This automatic update function is mostly a convenience for developers, otherwise you always had to manually construct a configuration which is tedious. If you use configurations for deployment I'd suggest not to use the update feature but deliver a verified working config to your users.

If you use a different development method or naming scheme in your project you can still use MCConfigs, it's just that the automatic update would not be usable.

• Bert -

_________________________________________________________________ Find a local pizza place, movie theater, and more….then map the best route! http://maps.live.com/?icid=hmtag1&FORM=MGAC01

On Mar 7, 2007, at 23:37 , Philippe Marschall wrote:

With MCC the specified Monticello versions are loaded in the given order from the given repositories.

Well, actually, I changed that about a year ago in the impara version:

http://source.impara.de/mc.html

It solves the problem of moving stuff between packages. Without that, moving methods or classes between packages is impossible to do correctly.

- Bert -

On Mar 8, 2007, at 0:07 , Philippe Marschall wrote:

2007/3/7, Bert Freudenberg bert@freudenbergs.de:

...

On Mar 7, 2007, at 23:37 , Philippe Marschall wrote:

...

With MCC the specified Monticello versions are loaded in the given order from the given repositories.

Well, actually, I changed that about a year ago in the impara version:

    http://source.impara.de/mc.html

It solves the problem of moving stuff between packages. Without that, moving methods or classes between packages is impossible to do correctly.

But creates a new one when a package assumes an other package is present and initialized. As a result strange things may happen in class side #initializes, and actually did happen for some of our projects so we reverted that behavior.

Well, there are workarounds for the init problem. There is no workaround for the moving problem, except for manually fixing up things when it's to late. So I'd opt for the former - but YMMV of course.

- Bert -

We don't have the moving problem (we build our images every night from scratch) but we do have the initialization problem. So the choice is pretty simple to us. The change provides no value to us only problems.

Philippe

2007/3/8, Ron Teitelbaum Ron@usmedrec.com:

I definitely agree with Bert. This really is a terrific solution and I have found it to be very useful. When I find a problem in code, I fix it and store the next numbered version in my own repository. My code loads automatically until a new version of the package is released, hopefully with my suggestions added. It's really cool.

Ron

...

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Wednesday, March 07, 2007 6:21 PM To: The general-purpose Squeak developers list Subject: Re: How-to Monticello Configuration

On Mar 8, 2007, at 0:07 , Philippe Marschall wrote:

...

2007/3/7, Bert Freudenberg bert@freudenbergs.de:

...

On Mar 7, 2007, at 23:37 , Philippe Marschall wrote:

...

With MCC the specified Monticello versions are loaded in the given order from the given repositories.

Well, actually, I changed that about a year ago in the impara version:

    http://source.impara.de/mc.html

It solves the problem of moving stuff between packages. Without that, moving methods or classes between packages is impossible to do correctly.

But creates a new one when a package assumes an other package is present and initialized. As a result strange things may happen in class side #initializes, and actually did happen for some of our projects so we reverted that behavior.

Well, there are workarounds for the init problem. There is no workaround for the moving problem, except for manually fixing up things when it's to late. So I'd opt for the former - but YMMV of course.

• Bert -

Thank you for this answers, I will try

2007/3/8, Andreas Raab andreas.raab@gmx.de:

Interesting. This is one of the cases where I fundamentally disagree with Bert's solution. Not because I don't have the "move problem" (I sure as hell do) but rather because of the troubles that are introduced by the out-of-order loading that happens with those modifications. For example, Tweak has a package "Scripting-Preload" that is required to be loaded *before* the "Scripting" packages. Works great if you load the packages independently but it can completely (and non-deterministically as we found out!) screw up if you load them via configurations. The whole idea of having a different load-order when you load the configuration vs. when loading the individual packages is extremely troublesome to me. It means that (due to the non-deterministic load-order) you cannot possibly predict the order in which things get loaded/initialized, which also means that given wide enough distribution, there is really *no* workaround for the initialization problem (since you cannot test in which order things get loaded) which is what ultimately led me to revert the changes in Croquet's MC variant.

Cheers,

• Andreas

Ron Teitelbaum wrote:

...

I definitely agree with Bert. This really is a terrific solution and I have found it to be very useful. When I find a problem in code, I fix it and store the next numbered version in my own repository. My code loads automatically until a new version of the package is released, hopefully with my suggestions added. It's really cool.

Ron

...

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Wednesday, March 07, 2007 6:21 PM To: The general-purpose Squeak developers list Subject: Re: How-to Monticello Configuration

On Mar 8, 2007, at 0:07 , Philippe Marschall wrote:

...

2007/3/7, Bert Freudenberg bert@freudenbergs.de:

...

On Mar 7, 2007, at 23:37 , Philippe Marschall wrote:

...

With MCC the specified Monticello versions are loaded in the given order from the given repositories.

Well, actually, I changed that about a year ago in the impara version:

    http://source.impara.de/mc.html

It solves the problem of moving stuff between packages. Without that, moving methods or classes between packages is impossible to do correctly.

But creates a new one when a package assumes an other package is present and initialized. As a result strange things may happen in class side #initializes, and actually did happen for some of our projects so we reverted that behavior.

Well, there are workarounds for the init problem. There is no workaround for the moving problem, except for manually fixing up things when it's to late. So I'd opt for the former - but YMMV of course.

• Bert -