On Wed, 20 Jul 2011, Phil Hord wrote:
On 07/20/2011 07:36 PM, Nicolas Pitre wrote:
On Wed, 20 Jul 2011, david@xxxxxxx wrote:
If the generation number is part of the repository then it's going to
be the same for everyone.
The actual generation number will be, and has to be, the same for
everyone with the same repository content, regardless of the cache used.
It is a well defined number with no room to interpretation.
Nonsense.
Even if the generation number is well-defined and shared by all clients, the
only quasi-essential definition is "for each A in ancestors_of(B), gen(A) <
gen(B)".
In practice, the actual generation number *will be the same* for everyone
with the same repository content, unless and until someone develops a
different calculation method. But there is no reason to require that the
number *has to be* the same for everyone unless you expect (or require)
everyone to share their gen-caches.
and I think this is why Linus is not happy with a cache. He is seeing this
as something that has significantly more value if it is going to be
consistant in a distributed manner than if it's just something calculated
locally that can be different from other systems.
if it's just locally generated, then I could easily see generation numbers
being different on different people's ssstems, dependin on the order that
they see commits (either locally generated or pulled from others)
If it's part of the commit, then as that commit gets propogated the
generation number gets propogated as well, and every repository will agree
on what the generation number is for any commit that's shared.
I agree that this consistancy guarantee seems to be valuable.
Surely there will be a competent and efficient gen-cache API. But most code
can just ask if B --contains A or even just use rev-list and benefit from the
increased speed of the answer. Because most code doesn't really care about
the gen numbers themselves, but only the speed of determining ancestry.
in that case, why bother with generation numbers at all? the improved data
based heristic seems to solve that problem.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html