153
153
"""Revision Identifiers
155
A revision identifier refers to a specific state of a branch's history. It can
156
be a revision number, or a keyword followed by ':' and often other
157
parameters. Some examples of identifiers are '3', 'last:1', 'before:yesterday'
155
A revision identifier refers to a specific state of a branch's history. It
156
can be expressed in several ways. It can begin with a keyword to
157
unambiguously specify a given lookup type; some examples are 'last:1',
158
'before:yesterday' and 'submit:'.
160
Alternately, it can be given without a keyword, in which case it will be
161
checked as a revision number, a tag, a revision id, a date specification, or a
162
branch specification, in that order. For example, 'date:today' could be
163
written as simply 'today', though if you have a tag called 'today' that will
160
166
If 'REV1' and 'REV2' are revision identifiers, then 'REV1..REV2' denotes a
161
167
revision range. Examples: '3647..3649', 'date:yesterday..-1' and
644
650
formats may also be introduced to improve performance and
647
Use the following guidelines to select a format (stopping
648
as soon as a condition is true):
650
* If you are working on an existing project, use whatever
651
format that project is using. (Bazaar will do this for you
654
* If you are using bzr-svn to interoperate with a Subversion
655
repository, use 1.14-rich-root.
657
* If you are working on a project with big trees (5000+ paths)
658
or deep history (5000+ revisions), use 1.14.
660
* Otherwise, use the default format - it is good enough for
663
If some of your developers are unable to use the most recent
664
version of Bazaar (due to distro package availability say), be
665
sure to adjust the guidelines above accordingly. For example,
666
you may need to select 1.9 instead of 1.14 if your project has
667
standardized on Bazaar 1.13.1 say.
669
Note: Many of the currently supported formats have two variants:
653
The newest format, 2a, is highly recommended. If your
654
project is not using 2a, then you should suggest to the
655
project owner to upgrade.
658
Note: Some of the older formats have two variants:
670
659
a plain one and a rich-root one. The latter include an additional
671
660
field about the root of the tree. There is no performance cost
672
661
for using a rich-root format but you cannot easily merge changes
673
662
from a rich-root format into a plain format. As a consequence,
674
663
moving a project to a rich-root format takes some co-ordination
675
664
in that all contributors need to upgrade their repositories
676
around the same time. (It is for this reason that we have delayed
677
making a rich-root format the default so far, though we will do
678
so at some appropriate time in the future.)
665
around the same time. 2a and all future formats will be
666
implicitly rich-root.
680
668
See ``bzr help current-formats`` for the complete list of
681
669
currently supported formats. See ``bzr help other-formats`` for