Rev 4181: There is some concern that we can't return all keys just by reading the index. in http://bzr.arbash-meinel.com/branches/bzr/jam-integration

[John Arbash Meinel]

At http://bzr.arbash-meinel.com/branches/bzr/jam-integration

------------------------------------------------------------
revno: 4181
revision-id: john at arbash-meinel.com-20090321021025-beae6pysdtuhlr32
parent: john at arbash-meinel.com-20090321020106-507m1ij4mk38cwh3
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: jam-integration
timestamp: Fri 2009-03-20 21:10:25 -0500
message:
  There is some concern that we can't return all keys just by reading the index.
-------------- next part --------------
=== modified file 'doc/developers/improved_chk_index.txt'
--- a/doc/developers/improved_chk_index.txt	2009-03-21 02:01:06 +0000
+++ b/doc/developers/improved_chk_index.txt	2009-03-21 02:10:25 +0000
@@ -447,5 +447,19 @@
 "group=FFFF entry = FFFF" to mean the same thing.
 
 
+``VF.keys()``
+-------------
+At the moment, some apis expect that you can list the references by reading
+all of the index. We would like to get away from this anyway, as it doesn't
+scale particularly well. However, with this format, we no longer store the
+exact value for the content. The content is self describing, and we *would* be
+storing enough to uniquely decide which node to read. Though that is actually
+contained in just 4-bytes (2-byte group, 2-byte group entry).
+
+We use ``VF.keys()`` during 'pack' and 'autopack' to avoid asking for content
+we don't have, and to put a counter on the progress bar. For the latter, we
+can just use ``index.key_count()`` for the former, we could just properly
+handle ``AbsentContentFactory``.
+
 .. 
   vim: ft=rst tw=78 ai