← 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: Robert Collins
  • Date: 2007-11-18 19:56:39 UTC
  • mfrom: (3006 +trunk)
  • mto: This revision was merged to the branch mainline in revision 3038.
  • Revision ID: robertc@robertcollins.net-20071118195639-m6zf3d5ljjw88kkn
Merge bzr.dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/incremental-push-pull.txt
32
32
1. New data is identified in the source repository.
33
33
2. That data is read from the source repository.
34
34
3. The same data is verified and written to the target repository in such a
35
 
   manner that it's not visible to readers until it's ready for use.
 
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
 
119
119
   ghost points from the target; plus a set difference search is needed on
120
120
   signatures.
121
121
 
122
 
 * Semantic level can probably be tuned, but as it's also complex I suggest
 
122
 * Semantic level can probably be tuned, but as its also complex I suggest
123
123
   deferring analysis for optimal behaviour of this use case.
124
124
 
125
125
 
180
180
validate the contents of a revision we need the new texts in the inventory for
181
181
the revision - to check a fileid:revisionid we need to know the expected sha1
182
182
of the full text and thus also need to read the delta chain to construct the
183
 
text as we accept it to determine if it's valid. Providing separate validators
 
183
text as we accept it to determine if its valid. Providing separate validators
184
184
for the chosen representation would address this.
185
185
e.g: For an inventory entry FILEID:REVISIONID we store the validator of the
186
186
full text :SHA1:. If we also stored the validator of the chosen disk
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
 
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