SQLite now allows multiple recursive SELECT statements in a single recursive CTE

fossil inode

To clarify, I'm advocating for "lineage" in the evolution sense rather than in the looser lay sense. It is a perfect match to "fossils" and "artifacts". We can then say things like "show me the lineage of the file currently called foo".

I believe jshoyer is using the term in this same sense, given the nature of his pun. (Ahahaha!)

the "configure" source file. That file is not currently part of the tree

Sure it is. If it weren't, we'd need some sort of "bootstrap" script to fetch it before you could build from a fresh checkout.

Moreover, if configure were missing from tip of trunk, I'd expect the current implementation of "fossil finfo configure" to not give results, yet it does. In fact, it gives more detail than the equivalent /finfo?name=configure call.

I poked into the gaps shown in the /finfo timeline, and it appears that these other configure files are from Autoconf, so they represent different lineages. The improved fossil finfo we're discussing here wouldn't show them at all, since you're implicitly giving it a commit ID to work with. /finfo would need another parameter (probably "ci") to make the same distinction: /finfo?name=configure&ci=trunk should show only the lineage of configure as traced back from tip-of-trunk.

How does fossil finfo currently trace the history anyway? I ask not as a mere curiosity but because it seems to have bearing on this thread's core problem.

Sometimes a single fossil inode can be composed of two or more filenames.

Yes, that's the rename case we're primarily concerned with in this case, not a "curiosity." The wished-for improvements to finfo would show that www/permutedindex.html was once called www/permutedindex.wiki. They're of the same lineage.

I still do not have a good way to assign a canonical name to a fossil inode....you could specify a filename and a specific check-in....

Yes, precisely: configure@9e816f0aa91..., meaning the file called configure as of the commit ID currently at tip-of-trunk.

This scheme means the lineage potentially has many names, but they all resolve to the same lineage. The only case where a lineage has only one name is when it's been committed once and never modified.

the name is not unique

I don't see see any reason that it has to be globally unique. That's why I proposed the local lineage ID idea: only within a given repo do you need to uniquely identify a lineage by a single scalar value, and then only as a local optimization for fast lookups.

They're analogous to RIDs in that way.

from Hacker News https://ift.tt/37xyi82