monticello bundles

bernhard at bernhard at
Mon Jan 19 22:38:35 UTC 2004

Hi Avi,

Avi Bryant <avi at> wrote:
> I agree.  It's time we had such a facility.  I was thinking about this 
> the other day, and here was my very simple minded suggestion:
> - You can add a named bundle to your working copy which will reference 
> any number of packages
> - If you select a bundle and click Save, new versions all of its 
> referenced packages will be saved to the repository
> - Also saved to the repository will be a "tag" file that lists the 
> UUIDs and version numbers of the newly saved packages
> - Selecting and loading these tag files will load all of the package 
> versions they list
> At first, we may not even need to make this recursive (bundles 
> referring to other bundles) although in the long run that could be 
> desirable.
First, let me say that I looked at Monticello and I like it very much! I
definitely will use it for all my Squeak programming in the future.* I
really like your design, the features you planned and how clean your
code is. Thank you very much for developing and sharing it!

I agree with Stephane that the bundle feature is very important. In my
eyes it is the most important missing feature of Monticello. It was the
feature I missed most. I like the design you outlined above. I find it
important that the bundles are versioned themselves. But perhaps that
was your intention, anyway?

Regarding recursive bundles: I think it might be even better if they
were not recursive. I have long time ENVY background. We used recursive
bundles, called Configuration Maps with Required Maps in ENVY
terminology, for some years and had problems. We had a lot of work
maintaining them. Then we switched to an approach where we used one
Configuration Map for each deliverable. In that way the same package
version ended up in multiple bundles. This approach turned out to work
much better for us.

Summary: I would find it great if you would add the bundle feature. :-)

I can really say that not having something like ENVY in Squeak was the
single most annoying thing when programming in Squeak.** Now with
Monticello that feeling is starting to come back. In some areas
Monticello even outperforms ENVY already, for instance the remote
repository feature. So in short, I am really enthusiastic!

By the way, I am interested in the possibility to use Monticello for
CampSmalltalk work. Did you think about that? I have started to port
Monticello to VisualAge Smalltalk. However, nothing works so far. I plan
to inform you if I have something showable.***

- Bernhard

* I am afraid I currently have very little time for Squeaking. However,
I still hope the situation improves again.
** This is something which is very difficult to explain to someone who
has never used a version and configuration management system like that.
*** In the process I found out that the following code compiles in
Squeak but does not in VAST nor in Dolphin: #; (I don't think I like
that behaviour.) Monticello relies on this in a test case, which
includes a literal array that contains Smalltalk code. I must admit that
I did not understand that code.

More information about the Squeak-dev mailing list