~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/overview.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-02-11 04:02:41 UTC
  • mfrom: (5017.2.2 tariff)
  • Revision ID: pqm@pqm.ubuntu.com-20100211040241-w6n021dz0uus341n
(mbp) add import-tariff tests

Show diffs side-by-side

added added

removed removed

Lines of Context:
4
4
 
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.  People writing plugins may also like to read the 
8
 
guide to `Integrating with Bazaar <integration.html>`_ for some specific
9
 
recipes.
 
7
people writing plugins.
10
8
 
11
9
If you have any questions, or if something seems to be incorrect, unclear
12
10
or missing, please talk to us in ``irc://irc.freenode.net/#bzr``, or write
13
 
to the Bazaar mailing list.  
14
 
 
15
 
 
16
 
Using bzrlib
17
 
############
18
 
 
19
 
Within bzr
20
 
==========
21
 
 
22
 
When using bzrlib within the ``bzr`` program (for instance as a bzr
23
 
plugin), bzrlib's global state is already available for use.
24
 
 
25
 
From outside bzr
26
 
================
27
 
 
28
 
To use bzrlib outside of ``bzr`` some global state needs to be setup.
29
 
bzrlib needs ways to handle user input, passwords, a place to emit
30
 
progress bars, logging setup appropriately for your program. The easiest
31
 
way to set all this up in the same fashion ``bzr`` does is to call
32
 
``bzrlib.initialize``. This returns a context manager within which bzrlib
33
 
functions will work correctly. See the pydoc for ``bzrlib.initialize`` for
34
 
more information. In Python 2.4 the ``with`` keyword is not supported and
35
 
so you need to use the context manager manually::
36
 
 
37
 
  # This sets up your ~/.bzr.log, ui factory and so on and so forth. It is
38
 
  # not safe to use as a doctest.
39
 
  library_state = bzrlib.initialize()
40
 
  library_state.__enter__()
41
 
  try:
42
 
      pass
43
 
      # do stuff here
44
 
  finally:
45
 
      library_state.__exit__(None, None, None)
46
 
 
47
 
 
48
 
Core classes
49
 
############
 
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.
 
13
 
 
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/>.
 
17
 
 
18
 
 
19
Essential Domain Classes
 
20
########################
 
21
 
 
22
The core domain objects within the bazaar model are:
 
23
 
 
24
* Transport
 
25
 
 
26
* Branch
 
27
 
 
28
* Repository
 
29
 
 
30
* WorkingTree
 
31
 
 
32
Transports are explained below. See http://bazaar-vcs.org/Classes/
 
33
for an introduction to the other key classes.
50
34
 
51
35
Transport
52
 
=========
 
36
#########
53
37
 
54
38
The ``Transport`` layer handles access to local or remote directories.
55
39
Each Transport object acts as a logical connection to a particular
62
46
Python file I/O mechanisms.
63
47
 
64
48
Filenames vs URLs
65
 
-----------------
 
49
=================
66
50
 
67
51
Transports work in terms of URLs.  Take note that URLs are by definition
68
52
only ASCII - the decision of how to encode a Unicode string into a URL
99
83
is also in the form of URL components.
100
84
 
101
85
 
102
 
WorkingTree
103
 
===========
104
 
 
105
 
A workingtree is a special type of Tree that's associated with a working
106
 
directory on disk, where the user can directly modify the files. 
107
 
 
108
 
Responsibilities:
109
 
 
110
 
 * Maintaining a WorkingTree on disk at a file path.
111
 
 * Maintaining the basis inventory (the inventory of the last commit done)
112
 
 * Maintaining the working inventory.
113
 
 * Maintaining the pending merges list.
114
 
 * Maintaining the stat cache.
115
 
 * Maintaining the last revision the working tree was updated to.
116
 
 * Knows where its Branch is located.
117
 
 
118
 
Dependencies:
119
 
 
120
 
 * a Branch
121
 
 * an MutableInventory
122
 
 * local access to the working tree
123
 
 
124
 
Branch
125
 
======
126
 
 
127
 
A Branch is a key user concept - its a single line of history that one or
128
 
more people have been committing to. 
129
 
 
130
 
A Branch is responsible for:
131
 
 
132
 
 * Holding user preferences that are set in a Branch.
133
 
 * Holding the 'tip': the last revision to be committed to this Branch. (And the revno of that revision.)
134
 
 * Knowing how to open the Repository that holds its history.
135
 
 * Allowing write locks to be taken out to prevent concurrent alterations to the branch.
136
 
 
137
 
Depends on:
138
 
 * URL access to its base directory.
139
 
 * A Transport to access its files.
140
 
 * A Repository to hold its history.
141
 
 
142
86
Repository
143
 
==========
 
87
##########
144
88
 
145
89
Repositories store committed history: file texts, revisions, inventories,
146
 
and graph relationships between them.  A repository holds a bag of
147
 
revision data that can be pointed to by various branches:
148
 
 
149
 
 * Maintains storage of various history data at a URL:
150
 
 
151
 
   * Revisions (Must have a matching inventory)
152
 
   * Digital Signatures
153
 
   * Inventories for each Revision. (Must have all the file texts available).
154
 
   * File texts
155
 
 
156
 
 * Synchronizes concurrent access to the repository by different
157
 
   processes.  (Most repository implementations use a physical 
158
 
   mutex only for a short period, and effectively support multiple readers
159
 
   and writers.)
 
90
and graph relationships between them.
160
91
 
161
92
Stacked Repositories
162
 
--------------------
 
93
====================
163
94
 
164
95
A repository can be configured to refer to a list of "fallback"
165
96
repositories.  If a particular revision is not present in the original