Elements of Monticello
Last updated at 7:16 am UTC on 28 September 2017
Packages
Monticello package
Snapshots
A Snapshot is the state of a Package at a particular point in time. Snapshots of the working copy of a package are created on demand when you want to browse a package. A snapshot is stored as normal fileout (with .st extension) file of all the classes and extension methods in the package.
Versions
A Version consists of a Snapshot of a Package along with the meta data such as ancestry info needed to support compares, merges etc. A Version is the lingua franca of the system. You save them, load them, give them to others, merge them, delete... you get the picture. Versions are implemented as a zip compressed file (with .mcz extension) Each such zipped folder contains three things:
- packaging information, i.e. the name of the package the code belongs to
- a fileOut of the package (the Snapshot of the Package source code)
- ancestry information
The third bit is just the metadata for the "full history of development." That is, what other versions contributed to the development of this version, who created them, when and why, etc. The source code to those versions is not included.
A Version ends up being fairly compact, so it's not unreasonable to distribute with a release. It's also important that it be present if somebody decides to start hacking on your Package. Then they can create a mcz with their Version of your package and it will have the correct ancestry information, enabling you to easily and correctly merge it back into your work.
Stated another way: It's not a full history of development - it's a snapshot of the code at a single point in time, with a UUID identifying that snapshot, and a record of the UUIDs of all the previous snapshots it's descended from. So it's a great thing to distribute.
Repositories
These are places to store your Versions. Unlike CVS, in which a Package is associated with one Repository, an MC Package can have Versions on many repositories. When adding a new Repository to use, you can choose from SqueakMap Cache, FTP, HTTP (webdav), SqueakMap Release, SMTP, or a directory somewhere on your hard drive (or network drive).
For example, if I have package Foo version 6, I could have Foo versions 1-4 being on my local hard drive, and 5-6 being on an ftp server. When you give me your Version, based on my version 5 on the ftp server, I can then merge it as I like. MC will look at the ancestry of your package and of the code I have in the image. MC will grab whatever Version, wherever it may be, and use it for merging etc. The result is a distributed development model.
Package cache
The package-cache is a local directory the Monticello uses to, um, cache any package that is loaded into a particular image in a directory. That means it is filled with .mcz files, whether it is a package you create in your image, or one you download from somewhere else.
When you use images in different directories you will have multiple package-
caches, and may hold many of the same packages. If MC is loaded into an image which is subsequently moved, MC will continue to use the package-cache in the directory the image was moved from. Otherwise MC creates a new package-cache in the
local directory. This can become a real mess and so some have used symlinks on unix systems to centralize it.
Why cache packages at all?
Oh, well you might be using an NFS mounted drive or something for a group of people to keep a repository on the filesystem. The package-cache is designed to hold a cached copy of any package you've seen. You wouldn't want your cached copies of SomeRandomPackageOnlyYouUse to be showing up in your work's UsefulPackageWeSell repository. (Julian Fitzell)
