← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/incremental-push-pull.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-06-06 08:37:14 UTC
  • mfrom: (2506.1.4 installer-0.17)
  • Revision ID: pqm@pqm.ubuntu.com-20070606083714-rt2za45t9gt5nqqh
(bialix,r=john,r=aaron) sanitize dev docs (performance-roadmap) &
 win32 installers improvements

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/incremental-push-pull.txt
1
1
Incremental push/pull
2
 
---------------------
 
2
=====================
3
3
 
4
4
This use case covers pulling in or pushing out some number of revisions which
5
5
is typically a small fraction of the number already present in the target
9
9
responsibility of the Repository object.
10
10
 
11
11
Functional Requirements
12
 
=======================
 
12
-----------------------
13
13
 
14
14
A push or pull operation must:
15
15
 * Copy all the data to reconstruct the selected revisions in the target
18
18
   data, corrupted data should not be incorporated accidentally.
19
19
 
20
20
Factors which should add work for push/pull
21
 
===========================================
 
21
-------------------------------------------
22
22
 
23
23
 * Baseline overhead: The time to connect to both branches.
24
24
 * Actual new data in the revisions being pulled (drives the amount of data to
27
27
   determination of what revisions to move around).
28
28
 
29
29
Push/pull overview
30
 
==================
 
30
------------------
31
31
 
32
32
1. New data is identified in the source repository.
33
33
2. That data is read from the source repository.
35
35
   manner that its not visible to readers until its ready for use.
36
36
 
37
37
New data identification
38
 
+++++++++++++++++++++++
 
38
~~~~~~~~~~~~~~~~~~~~~~~
39
39
 
40
40
We have a single top level data object: revisions. Everything else is
41
41
subordinate to revisions, so determining the revisions to propogate should be
124
124
 
125
125
 
126
126
Data reading
127
 
++++++++++++
 
127
~~~~~~~~~~~~
128
128
 
129
129
When transferring information about a revision the graph of data for the
130
130
revision is walked: revision -> inventory, revision -> matching signature,
156
156
 
157
157
 
158
158
Data Verification and writing
159
 
+++++++++++++++++++++++++++++
 
159
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
160
160
 
161
161
New data written to a repository should be completed intact when it is made
162
162
visible. This suggests that either all the data for a revision must be made
247
247
avoid ending up wth corrupt/bad data
248
248
 
249
249
Notes from London
250
 
=================
 
250
-----------------
251
251
 
252
252
 #. setup
253
253
 
268
268
   #. validate the sha1 of the full text of each transmitted text.
269
269
   #. validate the sha1:name mapping in each newly referenced inventory item.
270
270
   #. validate the sha1 of the XML of each inventory against the revision.
271
 
      *** this is proportional to tree size and must be fixed ***
 
271
      **this is proportional to tree size and must be fixed**
272
272
 
273
273
 #. write the data to the local repo.
274
274
    The API should output the file texts needed by the merge as by product of the transmission