/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/incremental-push-pull.txt

  • Committer: Ian Clatworthy
  • Date: 2007-06-06 05:56:03 UTC
  • mto: This revision was merged to the branch mainline in revision 2513.
  • Revision ID: ian.clatworthy@internode.on.net-20070606055603-monl116zotkbqn2y
commit.py clean-up including logging just to stderr, not bzr.log

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
 
subordinate to revisions, so determining the revisions to propagate should be
 
41
subordinate to revisions, so determining the revisions to propogate should be
42
42
all thats needed. This depends on revisions with partial data - such as those
43
43
with no signature - being flagged in some efficient manner.
44
44
 
94
94
      found to be a subset of the other, or a complete list of revisions to be
95
95
      transmitted is created.
96
96
 
97
 
 * Uncommon cases:
98
 
 
 
97
 * Uncommon cases: 
 
98
   
99
99
   1. Repositories with many projects or branches which are very old may
100
100
      require reading a lot of unrelated graph data.
101
101
 
109
109
 2. Determine one sided graph difference. To avoid obtaining a full graph over
110
110
    the wire this needs to be done without reference to the full graph, and
111
111
    with some logarthmic scaling algorithm. There are several already available
112
 
    for this.
 
112
    for this. 
113
113
 
114
114
With ghost and new-signature detection:
115
115
 
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
219
219
Data grouping:
220
220
 
221
221
* File per full identifier (fileid:revisionid:meta|content): 104000
222
 
* Delta-chain per object: object id count * constant overhead per object id
 
222
* Delta-chain per object: object id count * constant overhead per object id 
223
223
  (26 -> 80006)
224
224
* Collation/pack file: 1
225
225
 
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
 
254
 
   look at graph of revisions for ~N comits to deretmine eligibility for
 
254
   look at graph of revisions for ~N comits to deretmine eligibility for 
255
255
   if preserve mainline is on, check LH only
256
256
 
257
257
    identify objects to send that are not on the client repo
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