Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 4 and 14 (spanning 10 versions)
Revision 4 as of 2007-10-11 06:00:46
Size: 480
Editor: KeirMierle
Comment:
Revision 14 as of 2009-05-14 18:26:55
Size: 3892
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= A brief review of the Bazaar SCM model = #FORMAT rst
Line 3: Line 3:
== Repository == ======================================
A brief review of the Bazaar SCM model
======================================
Line 5: Line 7:
A repository contains revisions (what is created on each commit) and their relations.
Line 7: Line 8:
 * '''REVISION''':
   * revid identifier, typically look like `john@foo.com-2007090201-fab1028392`
   * List of parents (revid's)
   * List of properties (date, author??)
   * Commit message
High Level Objects
==================
Line 13: Line 11:
Files have their own revision graph. The nodes in a file's revision graph are all nodes in the revision graph. A file is ??? 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.

 * HEAD - A `Revision_id`_ corresponding to the tip of the branch.
 * Repository_ - The data store where the revisions are. Either in same or parent directory.
 * Other branch-specific information:
  
   * Associated branches
   * User configuration
   * Push/pull locations, etc.

Notes:

 * Each branch is uniquely identified by URL (which may just be a local path).
 * The history for a branch is linearized by walking the left-most parents of the revision graph starting at HEAD.

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 marker for 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
   * Timestamp
   * Message - Commit message
   * Timezone - What timezone the timestamp is relative to.

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

An inventory is literally a snapshot of the Tree_ for a particular revision. There is an Inventory_ for every Revision_.
The snapshot is represented as 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.

Notes:
 * The reason there is a revision ID for each record in the inventory is for storing the state of files which did not change in this revision. The revision may point to an earlier `Revision_id`_ than the revision associated with this Inventory_.
 * 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.)

.. vim tw=74 ft=rst

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.

  • HEAD - A Revision_id corresponding to the tip of the branch.
  • Repository - The data store where the revisions are. Either in same or parent directory.
  • Other branch-specific information:
    • Associated branches
    • User configuration
    • Push/pull locations, etc.

Notes:

  • Each branch is uniquely identified by URL (which may just be a local path).
  • The history for a branch is linearized by walking the left-most parents of the revision graph starting at HEAD.

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 marker for 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
    • Timestamp
    • Message - Commit message
    • Timezone - What timezone the timestamp is relative to.

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

An inventory is literally a snapshot of the Tree for a particular revision. There is an Inventory for every Revision. The snapshot is represented as 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.
Notes:
  • The reason there is a revision ID for each record in the inventory is for storing the state of files which did not change in this revision. The revision may point to an earlier Revision_id than the revision associated with this Inventory.
  • 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.)