[squeak-dev] [ANN] Monticello 2.0.25

Colin Putney cputney at wiresong.ca
Thu Oct 16 14:50:25 UTC 2008

On 16-Oct-08, at 3:32 AM, Lukas Renggli wrote:

> - I am following the "Bootstrapping" instructions in the
> documentation: After loading Release-cwp.25 all the packages MC2-* and
> Release are marked as dirty. In fact there are no changes.

Yes, I noticed this as well. I don't *think* it's a serious problem,  
but it definitely a bug.

> - I have some instances of MDFileRepository that have all inst-vars
> nil. On system startup I get a couple of debuggers because the system
> tries to rescan these files. Doing MDFileRepository allInstances on
> startup seems to be dangerous if there are thousands of instances, and
> this won't work well on GemStone.

FileRepositories should probably re-open their filestreams lazily  
rather than at startup. Do you have thousands of instances with nil  
variables? That really shouldn't happen.

> Some other thoughts:
> - I wonder, if you thought about using MC2 as a replacement for the
> changes-file? So every accept would commit the particular method to
> the repository, and the versions view would connect to the server and
> display all the versions of a particular element. When submitting the
> package, a slice would be created of the already existing elements. I
> think such a model would beautifully with MC2.

I have thought about that a little bit - kind of like ENVY. The  
original idea I had was to store source code in MC2, and us the  
changes file strictly for journaling. The changes file would be  
deleted when the image was saved, and you'd only use it to recover  
from crashes. But it would be pretty easy to hook a repository up to  
the SystemChangesNotifier as well, and have a versioned journal. Gotta  
sort out all the immediate issues first.

> - I wonder how I can calculate the diff between two arbitrary
> versions? This doesn't seem to be possible in the current GUI.

You're right, it's not yet possible. I've run into the need for this  
myself lately, so it's on my short-term todo list.

> - I am confused about "Project Config Slice" and "Union Slice". Is it
> correct that the "Project Config Slices" is like an "Union Slice", but
> automatically includes all the slices of the project? Are there other
> differences?

Project Config Slice and Union Slice are two quite different things. A  
union slice is the mathematical union of two other slices. The union  
of SliceA and SliceB includes all the code that is in either slice.  
The Release slice in the Monticello project is an example of that. For  
development, I have the code divided up into different packages, with  
dependencies between them. But a casual user of MC2 doesn't need all  
that structure, I created a Release slice that is the union of all the  
packages that are part of the release. To make a release, I take a  
snapshot of all the Release package and file it out. That way I get  
all the code in a single file, and the user doesn't have to do  
multiple file-ins in the correct order.

A Project Config slice is a meta-level slice. It's used for versioning  
Monticello Projects, not Smalltalk code. If you take a snapshot of a  
project, then load that snapshot into another image, you'll find that  
project now appears in the Project Browser, with all the same slices  
and repositories that were in the first image. This is how the boot  
strapping works:

- first load the basic code to Monticello
- then load the Monticello Project
- then reload all the code, using the project, so that our metadata is  
set up correctly

That last step is kind of tedious right now, but it'll get easier.

> - And please, please, please ... get rid of those cryptic labels for
> the elements. Nobody will ever even consider using it like that.



> PS: An early beta version of the Sourcetalk server will soon be put
> online, so that people can give a try.



More information about the Squeak-dev mailing list