|Deletions are marked like this.||Additions are marked like this.|
|Line 22:||Line 22:|
| * Pointer to a `Revision_id`_
| * 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.
|Line 25:||Line 30:|
|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_ ?)
* 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.
|Line 69:||Line 71:|
|An inventory is literally a snapshot of the Tree_ for a particular revision. There is a 1-1 mapping Revision_ to Inventory_.||An inventory is literally a snapshot of the Tree_ for a particular revision. There is an Inventory_ for every Revision_.|
A brief review of the Bazaar SCM model
High Level Objects
A location storing committed data. This can be shared between multiple branches.
A branch is a pointer into the revision graph and associated metadata.
- 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.
Files in a location that can be edited by the user. Always associated with a Branch, but may not be in the same location.
This section describes the data model for how data is stored.
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
- 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.
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.
- 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.
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.)