Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Revision 8 as of 2007-10-11 15:50:34

Clear message

A brief review of the Bazaar SCM model

High Level Objects


A location storing committed data. This can be shared between multiple branches.


Gives a pointer into the DAG the repository holds. Also a location for storing branch-specific information. (Associated branches, user configuration, etc.) These are uniquely identified by URL (which may just be a local path). They always have an associated Repository, which is either in the same directory, or in a parent directory (Branches are always in a subdir of their Repository ?)

Working Tree

Files in a location that can be edited by the user. Always associated with a Branch, but may not be in the same location.

Repository Objects

This section describes the data model for how data is stored.


Logically, this is a snapshot of a Tree, and its associated metadata. It is associated with a unique Revision_id.

Associated Metadata:

  • Parents - A list of Revision_id's.
  • Committer - The name of the person who

System Message: WARNING/2 (<string>, line 49)

Bullet list ends without a blank line; unexpected unindent.



In essence, a list of (file_id, revision) tuples, defining the state of the text for this revision. Also includes some of the metadata for easier processing (size, sha1sum, executable...)


Is more of an API, which is used as an interface managing the Inventory, and access to the actual texts of the files. (A WorkingTree or a RevisionTree.)

Alternatively, we could define Tree, and ignore the specifics of Inventory.


An arbitrary unqiue string which identifies a specific snaphot.


Rather than being defined soley by their path, files are uniquely identified by a file_id (arbitrary string). As files are moved and/or renamed, their file_id stays associated with the same logical file.

(Allows comparing 2 trees with arbitrary large history, and an arbitrary large number of renames, etc.)