Elements of Monticello
Last updated at 6:55 pm UTC on 1 December 2007
A package is a single "program" or "application" defined as a set of (1) core classes and/or (2) class extensions. Class extensions are limited to added methods. See Adding and removing classes or methods from a Monticello Package
Monticello uses simple category naming conventions to identify what classes and methods makes up a package. (1) The classes in the package all belong to the same class categories that begin with the package name. For example, the classes that are defined completely by Omnibrowser all have categories beginning with "Omnibrowser". (2) All of these extension methods are defined with a common method category that begins with an asterisk followed by the package name. For example, the extension methods that are defined by Omnibrowser all have method categories beginning with "*omnibrowser".
A package is a "unit of work", that is Monticello actions against it are "atomic". All of a package is loaded/saved or none of the package is loaded/saved. Packages are mutually exclusive. Since a class can belong to only one class category it can belong to only one package. Since a method can belong to only one method category it can belong to only one package (it can only be part of one packages extension to other classes).
This is define via PackageInfo (which can be subclassed.) Do this in a workspace:
PackageInfo allPackages explore
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.
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:
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.
- 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
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.
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.
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)