[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