On May 22, 2007, at 4:22 AM, Damien Cassou wrote:

> If yes, can you give me an overview of the current MC2 hierarchy? This
> would help me start in good conditions and maximize the chance to have
> a usable result at the end.
>

I'll take a stab at that. As Avi mentioned, design of MC2 follows  
from the idea that revision history would be attached to individual  
methods, rather than entire packages. The key concepts in MC2 are these:

Elements - these play the same role as MethodReferences. They are  
references to specific parts of a Smalltalk program. They're more  
fine-grained than Definitions in MC1 - you'll see separate elements  
for each instance variable, for example, so that they can referred to  
directly, rather than by implication in a class reference.

Variants - a variant describes the state of a particular element.  
That state might be "not present in the image," in the case of a  
RemovalVariant, or the properties of the element, in the case of a  
DefinitionVariant. One of the things that we noticed with MC1 is that  
the exact components of a definition are most likely to change, so we  
encode them using a PropertyDictionary instead of dedicated objects.

ImageProxy - this is a facade for the class structures of the image.  
It presents a protocol for querying the state of the image or  
modifying it using variants.

Version - this is the central class of MC2. It represents the state  
of an element at a particular point in the evolution of the system.  
It combines a variant with list of versions that have come before it.  
Each version has what we call a Hashstamp - combination of SHA1 hash  
and timestamp which uniquely identifies the version. A version's  
ancestry is a set of hashstamps specifying which versions are part of  
this version's history.

Slice - A slice is sub-set of the elements in the image. It's main  
responsibility is to define which elements are part of the slice and  
which are not. Slices can be based on any set of criteria -  
PackageInfo, ChangeSets, an explicit collection, whatever. Slices can  
overlap. Elements can belong to more than one slice at the same time.

Snapshot - this is a set of Versions which "go together." A snapshot  
is equivalent to an MCVersion in MC1. It's the unit at which code is  
moved between images.

WorkingCopy - I'm not terribly happy with this name, but I can't  
think of a better one. It keeps track of the state of the image with  
respect to versioning. It knows, for example, which versions image is  
based on, and can perform tasks like creating new versions based on  
the state of the image, or loading existing versions into the image.

Repositories - Repositories are similar to those in MC1, but have a  
different protocol and different performance characteristics.  
Conceptually, repositories are dictionaries, mapping hashstamps to  
versions or snapshots. This makes for a very fine-grained protocol -  
versions are loaded individually. That makes directory or HTTP  
repositories impractical, since loading a slice for a medium-size  
package would involve opening and reading hundreds of files. (A  
snapshot of OB, for example runs at over 600 versions).

Hope this helps.

Colin