13
13
% bzr log -r 1000..1100 # changes from 1000 to 1100
14
14
% bzr log -r 1000 # The changes in only revision 1000
16
Viewing merged revisions
17
------------------------
19
19
As distributed VCS tools like Bazaar make merging much easier than
20
it is in central VCS tools, the history of a branch may often show
20
it is in central VCS tools, the history of a branch may often contain
21
21
lines of development splitting off the mainline and merging back
22
22
in at a later time. Technically, the relationship between the
23
23
numerous revision nodes is known as a Directed Acyclic Graph or
26
In many cases though, you may only be interested in seeing the *mainline*
27
for a branch, namely the primary line of development within the DAG.
28
To do this, use the following command::
32
If you do this commonly, you may even wish to create an alias for it
33
as explained in `Using aliases`_.
26
In many cases, you typically want to see the mainline first and drill
27
down from there. The default behaviour of log is therefore to show
28
the mainline and indicate which revisions have nested merged revisions.
29
To explore the merged revisions for revision X, use the following command::
33
To see all revisions and all their merged revisions::
37
Note that the -n option is used to indicate the number of levels to display
38
where 0 means all. If that is too noisy, you can easily adjust the number
39
to only view down so far. For example, if your project is structured with
40
a top level gatekeeper merging changes from team gatekeepers, ``bzr log``
41
shows what the top level gatekeeper did while ``bzr log -n2`` shows what
42
the team gatekeepers did. In the vast majority of cases though, ``-n0``
added
removed
doc/en/user-guide/browsing_history.txt
