5
5
This document describes the key classes and concepts within Bazaar. It is
6
6
intended to be useful to people working on the Bazaar codebase, or to
7
people writing plugins.
7
people writing plugins. People writing plugins may also like to read the
8
guide to `Integrating with Bazaar <integrating.html>`_ for some specific
9
11
If you have any questions, or if something seems to be incorrect, unclear
10
12
or missing, please talk to us in ``irc://irc.freenode.net/#bzr``, or write
11
to the Bazaar mailing list. To propose a correction or addition to this
12
document, send a merge request or new text to the mailing list.
14
The current version of this document is available in the file
15
``doc/developers/overview.txt`` in the source tree, and available online
16
within the developer documentation, <http://doc.bazaar-vcs.org/developers/>.
19
Essential Domain Classes
20
########################
22
The core domain objects within the bazaar model are:
32
Transports are explained below. See http://bazaar-vcs.org/Classes/
33
for an introduction to the other key classes.
13
to the Bazaar mailing list.
38
22
The ``Transport`` layer handles access to local or remote directories.
39
23
Each Transport object acts as a logical connection to a particular
83
67
is also in the form of URL components.
73
A workingtree is a special type of Tree that's associated with a working
74
directory on disk, where the user can directly modify the files.
78
* Maintaining a WorkingTree on disk at a file path.
79
* Maintaining the basis inventory (the inventory of the last commit done)
80
* Maintaining the working inventory.
81
* Maintaining the pending merges list.
82
* Maintaining the stat cache.
83
* Maintaining the last revision the working tree was updated to.
84
* Knows where its Branch is located.
90
* local access to the working tree
95
A Branch is a key user concept - its a single line of history that one or
96
more people have been committing to.
98
A Branch is responsible for:
100
* Holding user preferences that are set in a Branch.
101
* Holding the 'tip': the last revision to be committed to this Branch. (And the revno of that revision.)
102
* Knowing how to open the Repository that holds its history.
103
* Allowing write locks to be taken out to prevent concurrent alterations to the branch.
106
* URL access to its base directory.
107
* A Transport to access its files.
108
* A Repository to hold its history.
89
113
Repositories store committed history: file texts, revisions, inventories,
90
and graph relationships between them.
114
and graph relationships between them. A repository holds a bag of
115
revision data that can be pointed to by various branches:
117
* Maintains storage of various history data at a URL:
118
* Revisions (Must have a matching inventory)
120
* Inventories for each Revision. (Must have all the file texts available).
123
* Synchronizes concurrent access to the repository by different
124
processes. (Most repository implementations use a physical
125
mutex only for a short period, and effectively support multiple readers
92
128
Stacked Repositories
95
131
A repository can be configured to refer to a list of "fallback"
96
132
repositories. If a particular revision is not present in the original
added
removed
doc/developers/overview.txt
