/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/planned-change-integration.txt

  • Committer: John Arbash Meinel
  • Date: 2009-10-12 15:55:26 UTC
  • mto: (4679.5.3 2.1-static-tuple-no-use)
  • mto: This revision was merged to the branch mainline in revision 4735.
  • Revision ID: john@arbash-meinel.com-20091012155526-b46tuz5cibebbnct
Change the _lookup function to use Quadratic Probing.

The main strength is that we get a bit of locality (collision resolution
looks quickly close to the location.)
The main weakness is that we don't use the upper bits of the hash to
induce divergence. So while we nicely handle collisions in neighboring
buckets (Quadratic means their resolution chains will diverge), if
two objects hash to the same bucket, their resolution chains are identical.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/planned-change-integration.txt
37
37
   provide strong feedback to the design process for those things which are
38
38
   considered optional or removable, so these APIs should be implemented
39
39
   before removing or making optional existing data.
40
 
 
 
40
 
41
41
 * Deprecating versioned files as a supported API: This collaborates with the
42
42
   Repository API but can probably be done by adding a replacement API for
43
43
   places where the versioned-file api is used. We may well want to keep a
54
54
   layer changes to inventories so while we can create a revision validator
55
55
   API, we cannot create the final one until we have the inventory structural
56
56
   changes completed.
57
 
 
 
57
 
58
58
 * Annotation caching API: This API is a prerequisite for new repository
59
59
   formats. If written after they are introduced we may find that the
60
60
   repository is lacking in functionality, so the API should be implemented
87
87
   of the newer API for accessing data about a file over time. It can be a
88
88
   separate step easily; but as it's in the same area of the library should not
89
89
   be done in parallel.
90
 
 
 
90
  
91
91
 * Repository stacking API: The key dependency/change required for this is that
92
92
   repositories must individually be happy with having partial data - e.g. many
93
93
   ghosts. However the way the API needs to be used should be driven from the
97
97
   On the data insertion side commit will want to generate new data. The
98
98
   commands pull, bundle, merge, push, possibly uncommit will want to copy
99
99
   existing data in a streaming fashion.
100
 
 
 
100
 
101
101
 * New container format: Its hard to tell what the right way to structure the
102
102
   layering is. Probably having smooth layering down to the point that code
103
103
   wants to operate on the containers directly will make this more clear. As
129
129
 * Delta storage optimisation: This has a strict dependency on a new repository
130
130
   format. Optimisation takes many forms - we probably cannot complete the
131
131
   desired optimisations under knits though we could use xdelta within a
132
 
   knit-variation.
 
132
   knit-variation. 
133
133
 
134
134
 * Greatest distance from origin cache: The potential users of this exist
135
135
   today, it is likely able to be implemented immediately, but we are not sure