Duy Nguyen <[email protected]> writes:
> On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup <[email protected]> wrote:
>> Since Git has a working facility for references that is catered to do
>> exactly this kind of mapping and already _does_, it seems like a
>> convenient path to explore.
>
> It will not scale. If you make those refs available for
> cloning/fetching, all of them will be advertised first thing when git
> starts negotiate. Imagine thousands of refs (and keep increasing) sent
> to the receiver at the beginning of every connection.
In current LilyPond repository:
git tag|wc
969 969 15161
In current Emacs mirror:
git tag|wc
1202 1202 15729
In current Git repository:
git tag|wc
498 498 4820
> Something like "reverse git-notes" may transfer more efficiently. Or
> we need to improve git protocol to handle massive refs better,
> something that's been discussed for a while without any outcome.
I think that even disregarding special use of references, _existing_
practice would already appear to warrant being able to deal with
thousands of refs in a reasonable manner.
It's a reasonable expectation to have a tag per (potentially
intermediate) release or release candidate. For any project publishing
reproducible daily snapshots, the threshold of 1000 will get reached
within few years.
Of course, it is relevant information to know that right _now_
references will not scale. But that does not seem like a defensible
long-term perspective.
--
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
