Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 7 and 8
Revision 7 as of 2007-10-11 14:15:44
Size: 909
Editor: KeirMierle
Comment:
Revision 8 as of 2007-10-11 15:50:34
Size: 2188
Editor: JohnMeinel
Comment: Just filling out some basics
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 repository contains revisions (what is created on each commit) and their relations.

 * A '''REVISION''' contains:
   * Revision ID (revid). Typically these look like `john@foo.com-2007090201-fab1028392`
   * List of parents (revid's)
   * List of properties (date, author??)
   * Commit message

A revision is roughly the same as a git commit object.

 * A '''INVENTORY''' contains:
   * Revision ID (revid). For a given commit, this revid matches with the corresponding revision.
   * List of (fileid, diff). The diff is the changes in file for fileid from X.parents[0] to X.

An inventory is roughly the same as a Mercurial (hg) manifest.
======================================
A brief review of the Bazaar SCM model
======================================
Line 22: Line 8:
== extraneous information to be integrated later ==
Files have their own revision graph. The nodes in a file's revision graph are all nodes in the revision graph. A file is ???
High Level Objects
==================

Repository
----------

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

Branch
------

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

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

Inventory
---------

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

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

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

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.

...

Inventory

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

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