/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/annotate.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/annotate.txt
 
1
Annotate
 
2
========
 
3
 
 
4
Broadly tries to ascribe parts of the tree state to individual commits.
 
5
 
 
6
There appear to be three basic ways of generating annotations:
 
7
 
 
8
If the annotation works by asking the storage layer for successive full texts
 
9
then the scaling of this will be proportional to the time to diff throughout
 
10
the history of thing being annotated.
 
11
 
 
12
If the annotation works by asking the storage layer for successive deltas
 
13
within the history of the thing being annotated we believe we can make it scale
 
14
broadly proportional to the depth of the tree of revisions of the annotated
 
15
object.
 
16
 
 
17
If the annotation works by combining cached annotations such that creating a
 
18
full text recreates annotations for it then it will scale with the cost of
 
19
obtaining that text.
 
20
 
 
21
Generally we want our current annotations but it would be nice to be able to do
 
22
whitespace annotations and potentially other diff based annotations.
 
23
 
 
24
Some things to think about:
 
25
 
 
26
 * Perhaps multiparent deltas would allow us to not store the cached
 
27
   annotations in each delta without losing performance or accuracy.
 
28