32
32
:Revision IDs: The unique identifier of a single revision, such as
33
33
``pqm@pqm.ubuntu.com-20110201161347-ao76mv267gc1b5v2``
34
:File IDs: The unique identifier of a single file. It is allocated when
35
a user does ``bzr add`` and is unchanged by renames.
34
:File IDs: The unique identifier of a single file.
37
36
By convention, in the bzrlib API, parameters of methods that are expected
38
37
to be IDs (as opposed to keys, revision numbers, or some other handle)
39
38
will end in ``id``, e.g. ``revid`` or ``file_id``.
40
Ids may be stored directly or they can be inferred from other
41
data. Native Bazaar formats store ids directly; foreign VCS
42
support usually generates them somehow. For example, the
43
Git commit with SHA ``fb235a3be6372e40ff7f7ebbcd7905a08cb04444``
44
is referred to with the revision ID
45
``git-v1:fb235a3be6372e40ff7f7ebbcd7905a08cb04444``. IDs are expected
51
File ids are unique identifiers for files. There are three slightly different
52
categories of file ids.
57
Tree file ids are used in the ``Tree`` API and can either be UTF-8 encoded
58
bytestrings or tuples of UTF-8 encoded bytestrings. Plain bytestrings
59
are considered to be the equivalent of a 1-tuple containing that
62
Tree file ids should be considered valid only for a specific tree context.
63
Note that this is a stricter interpretation than what the current bzr
64
format implementation provides - its file ids are persistent across runs
67
For some formats (most notably bzr's own formats) it's possible for the
68
implementation to specify the file id to use. In other case the tree
69
mandates a specific file id.
74
Inventories are specific to the bzr native format and are the main layer
75
below the ``Tree`` implementation of bzr. File ids in inventories can
76
only be UTF-8 encoded bytestrings. A single Tree object can be associated
77
with multiple inventories if there are nested trees.
79
Tree file ids for bzr formats are a tuple of inventory file ids for the file
80
in question. Each non-last item in the tuple refers to the tree
81
reference of an inner tree. The last item in the tuple refers to the
82
actual file. This means that lookups of file ids doesn't scale with
83
the number of nested trees.
85
Inventory file ids are only relevant for native Bazaar formats; foreign
86
formats don't use inventories.
91
Transform ids are used during tree transform operations (used by e.g. merge).
92
The same transform id is expected to be used for two instances of the
93
same file. At the moment transform ids are directly derived from file
94
ids, but in the future they could be based on other data too (e.g.
95
automatic rename detection or format-specific rules).
107
163
* `Developer guide to bzrlib transports <transports.html>`_
108
164
* API docs for ``bzrlib.transport.Transport``
169
Each control directory (such as ".bzr/") can contain zero or one
170
repositories, zero or one working trees and zero or more branches.
172
The ``BzrDir`` class is the ``ControlDir`` implementation that is
173
responsible for the ".bzr/" directory and its implementation. Plugins
174
that provide support for other version control systems can provide
175
other subclasses of ``ControlDir``.
121
188
Trees have an inventory and parents (an ordered list of zero or more
191
The implementation of ``Tree`` for Bazaar's own formats is based around
192
``Inventory`` objects which describe the shape of the tree. Each tree has
193
at least one inventory associated with it, which is available as the
194
``root_inventory`` attribute on tree. The tree can have more inventories
195
associated with it if there are references to other trees in it. These
196
references are indicated with ``tree-reference`` inventory entry at the
197
point where the other tree is nested. The tree reference entry contains
198
sufficient information for looking up the inventory associated with the
199
nested tree. There can be multiple layers of nesting.
201
Not each ``Tree`` implementation will necessarily have an associated
202
``root_inventory``, as not all implementations of ``Tree`` are based
203
around inventories (most notably, implementations of foreign VCS file