On 07/20/2011 08:58 PM, Nicolas Pitre wrote:
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)".
Sure. But what do you gain by making holes in the sequence?
Depends on the algorithm. Probably speed. Possibly more efficient
limited-cache building (jit-style discovery in reverse, as-needed, for
example).
What do you gain by enforcing contiguousness? Why not require all gen
numbers to be even? Or prime? ;)
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 with the above you clearly reinforced the argument _against_ storing
the generation number in the commit object. If you can imagine a
different calculation method already, and if it is actually useful, then
who knows if something even better could be done eventually.
Good. Nice to see I'm being self-consistent, then.
Phil
--
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