/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: Marius Kruger
  • Date: 2010-07-10 21:28:56 UTC
  • mto: (5384.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 5385.
  • Revision ID: marius.kruger@enerweb.co.za-20100710212856-uq4ji3go0u5se7hx
* Update documentation
* add NEWS

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/incremental-push-pull.txt
14
14
A push or pull operation must:
15
15
 * Copy all the data to reconstruct the selected revisions in the target
16
16
   branch. This is the goal of push and pull after all.
17
 
 * Reject corrupt data. As brz has no innate mechanism for discarding corrupted
 
17
 * Reject corrupt data. As bzr has no innate mechanism for discarding corrupted
18
18
   data, corrupted data should not be incorporated accidentally.
19
19
 
20
20
Factors which should add work for push/pull
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