rich roots conversion

[Ian Clatworthy]

John Arbash Meinel wrote:

> (An alternative solution is to turn last-modified into a 'non-official'
> value, somehow splitting it out of the inventory, etc.)

Maybe this is related and maybe but isn't, but now seems as good a
time as any to mention it. :-)

While chatting at the last sprint, I was grumbling to poolie about the
limitations (e.g. no info on end of lifecycle) and overhead of keeping
the per file graphs updated. He suggested that, being derived metadata,
we didn't need to strictly store them and could calculate them and cache
them on demand if required. I'm not sure how serious he was but I
thought I'd throw the idea out there for wider discussion.

Among other reasons, an advantage of late calculation is that we can change
the algorithm over time as our needs change. And this is *non-trivial*
logic already as jam explained to me in Brisbane. Adding features like
proper copy tracking makes me shiver when I think how it might complicate
the rules further still.

Outside log, what parts of our application use this metadata?
If we didn't calculate it as part of every commit, how much faster
would commit of a merge be, say? Do we *really* need per-file-graphs now
given other advances we're made like the CHK-based format?

IIRC, poolie said that git didn't store per-file-graph metadata but
hg did. Can anyone confirm that?

Ian C.