[bug 277537] [REVIEW] A highly specific reconcile

John Arbash Meinel john at arbash-meinel.com
Thu Oct 16 23:32:45 BST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 3-alt) Alternatively, we could start with the final nodes (since it is
> likely to be a smaller set). And then track back into ancestors until we
> get to nodes that are in the file set.
> 
> 
> I'm stopping this short because Martin and I just chatted briefly and
> I'd like to start a new email for those ideas.
> 
> John
> =:->

So here is another alternative.

Basically, build the per-file graph up from scratch, in the same way
that we generated it at commit time.

1) Start by determining all of the per-file nodes that you are
interested in. (find_text_key_references across all inventories.)

2) Get the whole-tree revision graph.

3) Iterate the whole-tree graph in topological order. For file-ids that
are "active" in this revision-id, add entries into their per-file graphs.

Essentially, you would be maintaining "inventories" for each 'head' that
you have active, though the inventories would be stripped down to just
(file_id, revision_id) tuples. And you would be updating them via a form
of deltas, rather than extracting them from scratch each time.

You could also make them more explicitly a CoW structure, or a Fulltext
+ deltas structure, which would make them more memory efficient. (Or a
'current' + backwards-deltas in case you have to track back to a parent
you didn't cache.)

I don't like that we are re-implementing inventories, but they would at
least be under different constraints, so they could be more heavily
optimized for this specific case.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj3wQ0ACgkQJdeBCYSNAAOw2wCgwcgXyTcPuf1K3u8gqRD/6UTw
EfgAnAg31pd0wXK7T53y84Lt1Z80aaQ2
=pYhG
-----END PGP SIGNATURE-----



More information about the bazaar mailing list