[MERGE] Describe a hash trie based inventory

Vincent Ladeuil v.ladeuil+lp at free.fr
Tue Aug 26 10:00:40 BST 2008


>>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:

    robert> On Tue, 2008-08-26 at 09:45 +0200, Vincent Ladeuil wrote:
    >> 
    >> Have you considered handling the inventory as a flat file-ids list
    >> instead of a path tree ?

    robert> Well, essentially this does treat it as a flat list
    robert> of file ids - the list is stored via the hash trie,
    robert> with the file id as the key.

Ok, thanks for clarifying, I was unsure.

    >> This could keep the nice properties of hash tries while
    >> addressing the 10.000 files in one directory corner case as well
    >> as the 'Goal satisfaction point 4' above.

    robert> The only issue with point 4 is the multiple lookups -
    robert> to solve that you need to have the full path stored
    robert> in some fashion, and that implies recursively
    robert> altering every entry when its parent is renamed even
    robert> if the entry itself isn't altered.

IMHO, if the full path is a property of the entry then renaming a
parent effectively *changes* every child entry. So we are still
in O(changes) whatever the tree *above* that point looks like.

Point 4 was: 
  
  Success, though each change will need its parents looked up as
  well so it will be proportional to the changes + the
  directories above the changed path.

That made me think that a change of a child implied a change on
every parent, but if we manage a flat list of file-ids, this is
irrelevant. No ?

           Vincent



More information about the bazaar mailing list