Stefan Beller <sbeller@xxxxxxxxxx> writes:
> A race condition may be a serious objection then? Once people believe the
> refs can scale fairly well they will use it, which means blasting the ref
> advertisement will become very worse over time.
I think we are already in agreement about that case:
A misdetected case between (new client, new server) pair might go
like this:
- new client connects and sends that no-op.
- new server accepts the connection, but that no-op probe has
not arrived yet.. It misdetects the other side as a v1
client and it starts blasting the ref advertisement.
- new client notices that the ref advertisement has the
capability bit and the server is capable of v2 protocol. it
waits until the server sends "sorry, I misdetected" message.
- new server eventually notices the "no-op probe" while blasting
the ref advertisement and it can stop in the middle.
hopefully this can happen after only sending a few kilobytes
among megabytes of ref advertisement data ;-). The server
sends "sorry, I misdetected" message to synchronise.
- both sides happily speak v2 from here on.
However, I do not think it needs to become worse over time, because
we can change and adjust as the user population and their use
patterns evolve. For example, you can introduce a small delay
before the new versions of server starts the v1 advertisement, and
make that delay longer and longer over time, as the population of
v1-only clients go down, for example.
Difficulty (see J6t's comment) in other implementations may be a
more important roadblocks. It seems, however, that our current
thinking is that it is OK to do the "allow new v1 clients to notice
the availabilty of v2 servers, so that they can talk v2 the next
time" thing, so my preference is to throw this "client first and let
server notice" into "maybe doable but not our first choice" bin, at
least for now.
Thanks.
--
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