← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/repository.txt

  • Committer: Ian Clatworthy
  • Date: 2009-09-09 15:30:59 UTC
  • mto: (4634.37.2 prepare-2.0)
  • mto: This revision was merged to the branch mainline in revision 4689.
  • Revision ID: ian.clatworthy@canonical.com-20090909153059-sb038agvd38ci2q8
more link fixes in the User Guide

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/repository.txt
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
246
246
  offset for the data record in the knit, the byte length for the data
247
247
  record in the knit and the no-end-of-line flag.
248
248
 
249
 
It's important to note that knit repositories cannot be regenerated by
 
249
Its important to note that knit repositories cannot be regenerated by
250
250
scanning .knits, so a mapped index is still irreplaceable and must be
251
251
transmitted on push/pull.
252
252
 
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
273
273
hashing the full file. OTOH hashing the full file is a cheap way to detect
274
274
bit-errors in transfer (such as windows corruption). Non-reused file names
275
275
are required for data integrity, as clients having read an index will
276
 
readv at arbitrary times later.
 
276
readv at arbitrary times later. 
277
277
 
278
278
Discovery of files
279
279
~~~~~~~~~~~~~~~~~~
304
304
============================
305
305
 
306
306
Repositories try to provide a consistent view of the data within them
307
 
within a 'lock context'.
 
307
within a 'lock context'. 
308
308
 
309
309
Locks
310
310
-----
318
318
write lock, and allow write_groups to be acquired. For some repositories
319
319
the presence of a write lock is exclusive to a single client, for others
320
320
which are lock free or use server side locks (e.g.  svn), the write lock
321
 
simply provides the cache context.
 
321
simply provides the cache context. 
322
322
 
323
323
Write Groups
324
324
------------