/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: Vincent Ladeuil
  • Date: 2012-01-18 14:09:19 UTC
  • mto: This revision was merged to the branch mainline in revision 6468.
  • Revision ID: v.ladeuil+lp@free.fr-20120118140919-rlvdrhpc0nq1lbwi
Change set/remove to require a lock for the branch config files.

This means that tests (or any plugin for that matter) do not requires an
explicit lock on the branch anymore to change a single option. This also
means the optimisation becomes "opt-in" and as such won't be as
spectacular as it may be and/or harder to get right (nothing fails
anymore).

This reduces the diff by ~300 lines.

Code/tests that were updating more than one config option is still taking
a lock to at least avoid some IOs and demonstrate the benefits through
the decreased number of hpss calls.

The duplication between BranchStack and BranchOnlyStack will be removed
once the same sharing is in place for local config files, at which point
the Stack class itself may be able to host the changes.

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 its not visible to readers until its ready for use.
 
35
   manner that it's not visible to readers until it's 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 its also complex I suggest
 
122
 * Semantic level can probably be tuned, but as it's 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 its valid. Providing separate validators
 
183
text as we accept it to determine if it's 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