From: Jeff King <email@example.com> To: Sascha Cunz <firstname.lastname@example.org> Cc: "Shawn Pearce" <email@example.com>, "Junio C Hamano" <firstname.lastname@example.org>, "Ævar Arnfjörð" <email@example.com>, "Git Mailing List" <firstname.lastname@example.org> Subject: Re: upload-pack is slow with lots of refs Date: Thu, 4 Oct 2012 20:20:48 -0400 [thread overview] Message-ID: <20121005002048.GA17586@sigill.intra.peff.net> (raw) In-Reply-To: <7939878.c2fCDAx1ds@blacky> On Thu, Oct 04, 2012 at 11:52:13PM +0200, Sascha Cunz wrote: > Would it be possible to use this workflow: > > - Every client connects per default to v1 > > - If server is capable of v2, it sends a flag along with the usual response > (A v1 server will obviously not send that flag) That is more or less the strategy we use for existing extensions (your "flag" is a space-separated list of capability strings). But in this case, the idea would be to change what the "usual response" is. Since a v1 client would be expecting the response, we must send it, but at that point it is too late to make the change. So we need to see some flag from the client before the server says anything. And the problem is that the client sending that flag will break v1 servers, and the client would need to waste time doing a retry when connecting to the (initially more common) v1 servers. > - If client is also capable of v2 and gets the flag, it enables v2 for > just that remote (probably unless the user said, "i never want to") > > - Next time the client connects to that remote it will use v2. So yeah, that would work to help with the wasted time. We'd have git-upload-pack2 to do the v2 protocol, but the v1 git-upload-pack for the server would say "by the way, next time you connect, try v2 first". So the client would have to store a version number for each remote. Which is not too onerous. Another way to think of it is phasing it in like this: 1. Add v2 support to client and server. Initially, clients try only v1. 2. Add a remote.*.preferProtocol config option, defaulting to v1. This lets people turn on v2 for remotes they know support it. If v2 fails, still fall back to v1. 3. Add a server upload-pack capability that says "by the way, try v2 next time". Have the client set the preferProtocol config option for a remote if we see that capability. 4. Wait a while until v2 is very popular. 5. Switch the default for preferProtocol to v2 (but still fall back to v1). So always fall back and remain compatible, and let the config option just be an optimization to avoid extra failed requests. > I'm not sure, if this is possible, since I think to remember that I have read > in the Documentation folder something along the line: Capabilities announced > from the server mean "I want you to use exactly these flags". No, the server capability says "I can do this", and the client should respond with "I want you to do this". Because the server might be talking to an older client that does not know what "this" is, it must handle the case that the capability does not come back. -Peff
next prev parent reply other threads:[~2012-10-05 0:21 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-03 12:36 Ævar Arnfjörð Bjarmason 2012-10-03 13:06 ` Nguyen Thai Ngoc Duy 2012-10-03 18:03 ` Jeff King 2012-10-03 18:53 ` Junio C Hamano 2012-10-03 18:55 ` Jeff King 2012-10-03 19:41 ` Shawn Pearce 2012-10-03 20:13 ` Jeff King 2012-10-04 21:52 ` Sascha Cunz 2012-10-05 0:20 ` Jeff King [this message] 2012-10-05 6:24 ` Johannes Sixt 2012-10-05 16:57 ` Shawn Pearce 2012-10-08 15:05 ` Johannes Sixt 2012-10-09 6:46 ` Shawn Pearce 2012-10-09 20:30 ` Johannes Sixt 2012-10-09 20:46 ` Johannes Sixt 2012-10-03 20:16 ` Ævar Arnfjörð Bjarmason 2012-10-03 21:20 ` Jeff King 2012-10-03 22:15 ` Ævar Arnfjörð Bjarmason 2012-10-03 23:15 ` Jeff King 2012-10-03 23:54 ` Ævar Arnfjörð Bjarmason 2012-10-04 7:56 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King 2012-10-04 7:58 ` [PATCH 1/4] peel_ref: use faster deref_tag_noverify Jeff King 2012-10-04 18:24 ` Junio C Hamano 2012-10-04 8:00 ` [PATCH 2/4] peel_ref: do not return a null sha1 Jeff King 2012-10-04 18:32 ` Junio C Hamano 2012-10-04 8:02 ` [PATCH 3/4] peel_ref: check object type before loading Jeff King 2012-10-04 19:06 ` Junio C Hamano 2012-10-04 19:41 ` Jeff King 2012-10-04 20:41 ` Junio C Hamano 2012-10-04 21:59 ` Jeff King 2012-10-04 8:03 ` [PATCH 4/4] upload-pack: use peel_ref for ref advertisements Jeff King 2012-10-04 8:04 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King 2012-10-04 9:01 ` Ævar Arnfjörð Bjarmason 2012-10-04 12:14 ` Nazri Ramliy 2012-10-03 22:32 ` upload-pack is slow with lots of refs Ævar Arnfjörð Bjarmason 2012-10-03 23:21 ` Jeff King 2012-10-03 23:47 ` Ævar Arnfjörð Bjarmason 2012-10-03 19:13 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20121005002048.GA17586@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: upload-pack is slow with lots of refs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).