Version history in Monticello 2 isn’t tied to packages. Instead, it introduces the concept of slices.
A slice is, quite simply, a set of elements - an arbitrary slice of the code in the image. We can define several different kinds of slices:
Packages
In Squeak, we can use PackageInfoSlice to get packages identical to those used by Monticello 1. In other dialects we’d create slices to interface with the native packaging code - PackageSlice and BundleSlice in VisualWorks for example.
Change Sets
A ChangeSet also defines an interesting slice of the image, and by implementing ChangeSetSlice, we can make them versionable and mergeable, just like packages. I’m really looking forward to this one, actually. It’ll make the lives of package maintainers easier, since contributors can just send them change sets rather than full packages.
Modules
Lately, I’ve become interested in combining Monticello with Spoon. One of the keys to that integration would be to create a NaiadSlice. This would define a slice based on the elements involved in executing a given Smalltalk expression.
Explicit
Probably the simplest kind of slice is defined with a collection of elements. At some point, I’d like to create a UI for easily creating an ExplicitSlice. I’m imagining a window which lists the contents of the slice, and accepts new elements via drag and drop from OmniBrowser. For now, though, ExplicitSlices can be created pogrammatically, and are really handy for testing.
Others
Although they’re probably not useful for everyday development, there are other kinds of slice one might want. A FileOutSlice would enumerate all the elements in a particular chunk file. We could do the same thing with the sources and changes files. We could create a slice that scanned the changes file and included all elements modified between a pair of snapshot markers. When demoing Monticello 2 I sometimes joke about creating a slice that includes all the elements that match a given rewrite rule. I don’t know how useful it would be, but why not?
For the moment, I’ve only implemented ExplicitSlice and PackageInfoSlice, since they’re needed to acheive feature parity with Monticello 1.
Saving Slices
It's true that we don't commit slices to the repository, yes. But slices don't really "contain" elements, they just enumerate them. (MDExplicitSlice is the obvious exception to this, but it's meant mainly for testing.) The role of a slice is to divide the image into two parts: the parts that belong to the slice and the parts that don't. MDPackageInfoSlice does this on the basis of a PackageInfo instance - anything in the package belongs to the slice, anything not in the package does not. The plan is to have other types of slices as well, based on ChangeSets, RefactoringEnvironments, and anything else that seems interesting.
Also, elements aren't committed to the repository per se, but only as part of an MDVersion.
When a snapshot is created, a slice decides which methods should be part of it, and the resulting snapshot describes the state of those methods and their versioning history.
