rich roots conversion

[Jelmer Vernooij]

On Wed, Apr 15, 2009 at 10:28:00PM +1000, Ian Clatworthy wrote:
> 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?

I can confirm git doesn't store per-file-graph metadata, it derives
this sort of data whenever it needs it.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090415/906aa0fc/attachment-0001.pgp