Bazaar

Bazaar

 

Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments
Differences between revisions 8 and 9
⇤ ← Revision 8 as of 2007-10-11 15:50:34 →
Size: 2188
Editor: JohnMeinel
Comment: Just filling out some basics
← Revision 9 as of 2007-10-11 16:43:25 → ⇥
Size: 3341
Editor: KeirMierle
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
Gives a pointer into the DAG the repository holds. Also a location for storing A branch is a pointer into the revision graph and associated metadata.

 * Pointer to a `Revision_id`_
 * Pointer

Gives a pointer into the DAG the repository holds.
Also a location for storing
Line 39: Line 45:
Line 43: Line 48:
Logically, this is a snapshot of a Tree_, and its associated metadata. It is
associated with a unique `Revision_id`_.		 A revision is a snapshot of a Tree_ and its associated metadata. Each revision
is a record with the following fields:
Line 46: Line 51:
Associated Metadata:  * `Revision_id`_ - Unique identifier for this revision.
 * Parents - A list of `Revision_id`_'s.
 * Properties - A dictionary of metadata. Generally, the meta data is at least:
   * Committer - Who committed the revision.
   * Date - When the revision was committed
   * (other metadata)
Line 48: Line 58:
 * Parents - A list of `Revision_id`_'s.
 * Committer - The name of the person who
 ...		 The DAG (directed acyclic graph) implied by the set of revisions is the
revision graph of the project. (add here)

A Bazaar revision is equivalent to a git commit object.
Line 55: Line 66:
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...)		 A list of ``(file_id, revision)`` tuples, defining the state of the
text (i.e. contents of the file) for a particular revision. In detail,
an Inventory_ is a series of records each with the following fields:

 * `File_id`_ - Unique identifier for the file. Same for all revisions of the file.
 * Revision - The `Revision_id`_ in which this variation of this file was introduced.
 * Parent ID - `File_id`_ of the parent directory, or ROOT_ID.
 * Name - The filename relative to the parent directory.
 * Executable - Indicates that this file should be executable on systems that support it.
 * Text SHA1 - SHA-1 hash of the full text of the file (not the delta).
 * Text size - Size in bytes of the text of the file.

The tree implied by the Parent ID fields is a directory tree, and is not
related to the revision tree.

This is similar to a Hg manifest.

A brief review of the Bazaar SCM model

High Level Objects

Repository

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

Branch

A branch is a pointer into the revision graph and associated metadata.

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.

Revision

A revision is a snapshot of a Tree and its associated metadata. Each revision is a record with the following fields:

  • Revision_id - Unique identifier for this revision.
  • Parents - A list of Revision_id's.
  • Properties - A dictionary of metadata. Generally, the meta data is at least: * Committer - Who committed the revision. * Date - When the revision was committed * (other metadata)

The DAG (directed acyclic graph) implied by the set of revisions is the revision graph of the project. (add here)

A Bazaar revision is equivalent to a git commit object.

Inventory

A list of (file_id, revision) tuples, defining the state of the text (i.e. contents of the file) for a particular revision. In detail, an Inventory is a series of records each with the following fields:

  • File_id - Unique identifier for the file. Same for all revisions of the file.
  • Revision - The Revision_id in which this variation of this file was introduced.
  • Parent ID - File_id of the parent directory, or ROOT_ID.
  • Name - The filename relative to the parent directory.
  • Executable - Indicates that this file should be executable on systems that support it.
  • Text SHA1 - SHA-1 hash of the full text of the file (not the delta).
  • Text size - Size in bytes of the text of the file.

The tree implied by the Parent ID fields is a directory tree, and is not related to the revision tree.

This is similar to a Hg manifest.

Tree

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.

Revision_id

An arbitrary unqiue string which identifies a specific snaphot.

File_id

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.)