/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/repository.txt

  • Committer: Ian Clatworthy
  • Date: 2007-08-31 00:35:37 UTC
  • mto: (2779.1.1 ianc-integration)
  • mto: This revision was merged to the branch mainline in revision 2783.
  • Revision ID: ian.clatworthy@internode.on.net-20070831003537-29b1erv58zwb0kh7
Get test suite fully working again

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/repository.txt
8
8
:Date: 2007-07-08
9
9
 
10
10
This document describes the services repositories offer and need to offer
11
 
within bzrlib.
 
11
within brlib.
12
12
 
13
13
 
14
14
.. contents::
44
44
                    introduced by a set of revisions in some cheap form, insert
45
45
                    data from a stream, validate data during insertion.
46
46
Garbage Collection  Exclusive lock the repository preventing readers.
47
 
Revert              Delta from working tree to historical tree, and then
 
47
Revert              Delta from working tree to historical tree, and then 
48
48
                    arbitrary file access to obtain the texts of differing
49
49
                    files.
50
50
Uncommit            Revision graph access.
98
98
                     Scan the inventory data introduced during the selected
99
99
                     revisions, and grab the on disk data for the found
100
100
                     file texts, annotation region data, per-file-graph
101
 
                     data, piling all this into a stream.
 
101
                     data, piling all this into a stream. 
102
102
Garbage Collection   Basically a mass fetch of all the revisions which
103
103
                     branches point at, then a bait and switch with the old
104
104
                     repository thus removing unreferenced data.
106
106
                     to, inventory extraction of that revision,
107
107
                     dirblock-order file text extract for files that were
108
108
                     different.
109
 
Uncommit             Revision graph access to synthesise pending-merges
 
109
Uncommit             Revision graph access to synthesise pending-merges 
110
110
                     linear access down left-hand-side, with is_ancestor
111
111
                     checks between all the found non-left-hand-side
112
112
                     parents.
113
113
Status               Lookup the revisions added by pending merges and their
114
114
                     commit messages. Then an inventory difference between
115
115
                     the trees involved, which may include a working tree.
116
 
                     If there is a working tree involved then the file
 
116
                     If there is a working tree involved then the file 
117
117
                     fingerprint for cache-misses on files will be needed.
118
118
                     Note that dirstate caches most of this making
119
119
                     repository performance largely irrelevant: but if it
256
256
delta-compressed ever. Likewise signatures do not need the parent pointers
257
257
at all as there is no 'signature graph'.
258
258
 
259
 
Data
 
259
Data 
260
260
----
261
261
 
262
262
Moving to pack based repositories
271
271
interesting to have it be deterministic based on content, but there are no
272
272
specific problems we have solved by doing that, and doing so would require
273
273
hashing the full file. OTOH hashing the full file is a cheap way to detect
274
 
bit-errors in transfer (such as windows corruption). Non-reused file names
275
 
are required for data integrity, as clients having read an index will
276
 
readv at arbitrary times later.
 
274
bit-errors in transfer (such as windows corruption).
277
275
 
278
276
Discovery of files
279
277
~~~~~~~~~~~~~~~~~~
300
298
Choosing compression/delta support
301
299
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
302
300
 
 
301
 
303
302
Caching and writeing of data
304
303
============================
305
304
 
306
305
Repositories try to provide a consistent view of the data within them
307
 
within a 'lock context'.
 
306
within a 'lock context'. 
308
307
 
309
308
Locks
310
309
-----
318
317
write lock, and allow write_groups to be acquired. For some repositories
319
318
the presence of a write lock is exclusive to a single client, for others
320
319
which are lock free or use server side locks (e.g.  svn), the write lock
321
 
simply provides the cache context.
 
320
simply provides the cache context. 
322
321
 
323
322
Write Groups
324
323
------------