← 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: Martin Pool
  • Date: 2007-06-15 07:01:24 UTC
  • mfrom: (2528 +trunk)
  • mto: This revision was merged to the branch mainline in revision 2530.
  • Revision ID: mbp@sourcefrog.net-20070615070124-clpwqh5gxc4wbf9l
Merge trunk

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
240
240
transmission method to reasonably closely match the desired write ordering
241
241
locally. This suggests that once we decide on the best local storage means we
242
242
should design the api.
 
243
 
 
244
 
 
245
take N commits from A to B, if B is local then merge changes into the tree.
 
246
copy ebough data to recreate snapshots
 
247
avoid ending up wth corrupt/bad data
 
248
 
 
249
Notes from London
 
250
-----------------
 
251
 
 
252
 #. setup
 
253
 
 
254
   look at graph of revisions for ~N comits to deretmine eligibility for 
 
255
   if preserve mainline is on, check LH only
 
256
 
 
257
    identify objects to send that are not on the client repo
 
258
      - revision - may be proportional to the graph
 
259
      - inventory - proportional to work
 
260
      - texts     - proportional to work
 
261
      - signatures - ???
 
262
 
 
263
 #. data transmission
 
264
 
 
265
  * send data proportional to the new information
 
266
  * validate the data:
 
267
 
 
268
   #. validate the sha1 of the full text of each transmitted text.
 
269
   #. validate the sha1:name mapping in each newly referenced inventory item.
 
270
   #. validate the sha1 of the XML of each inventory against the revision.
 
271
      **this is proportional to tree size and must be fixed**
 
272
 
 
273
 #. write the data to the local repo.
 
274
    The API should output the file texts needed by the merge as by product of the transmission
 
275
 
 
276
 #. tree application
 
277
 
 
278
Combine the output from the transmission step with additional 'new work data' for anything already in the local repository that is new in this tree.
 
279
should write new files and stat existing files proportional to the count of the new work and the size of the full texts.