← 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: toto at example
  • Date: 2010-09-27 19:31:45 UTC
  • mfrom: (5050.17.27 2.2)
  • mto: This revision was merged to the branch mainline in revision 5448.
  • Revision ID: toto@example.com-20100927193145-bly1dw5wjd23hiwy
Merge lp:bzr/2.2 into trunk including fixes for #644855, #646133, #632387

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
~~~~~~~~~~~~~~~~~~~~~~~
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