From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Erik van Zijst <erik.van.zijst@gmail.com>,
git@vger.kernel.org, ssaasen@atlassian.com,
mheemskerk@atlassian.com
Subject: Re: [ANNOUNCE] Git Merge Contributor Summit topic planning
Date: Wed, 01 Feb 2017 10:06:15 -0800 [thread overview]
Message-ID: <xmqqh94dpyzs.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170201145300.4pn3faodhdb72jly@sigill.intra.peff.net> (Jeff King's message of "Wed, 1 Feb 2017 15:53:00 +0100")
Jeff King <peff@peff.net> writes:
> If you _can_ do that latter part, and you take "I only care about
> resumability" to the simplest extreme, you'd probably end up with a
> protocol more like:
>
> Client: I need a packfile with this want/have
> Server: OK, here it is; its opaque id is XYZ.
> ... connection interrupted ...
> Client: It's me again. I have up to byte N of pack XYZ
> Server: OK, resuming
> [or: I don't have XYZ anymore; start from scratch]
>
> Then generating XYZ and generating that bundle are basically the same
> task.
The above allows a simple and naive implementation of generating a
packstream and "tee"ing it to a spool file to be kept while sending
to the first client that asks XYZ.
The story I heard from folks who run git servers at work for Android
and other projects, however, is that they rarely see two requests
with want/have that result in an identical XYZ, unless "have" is an
empty set (aka "clone"). In a busy repository, between two clone
requests relatively close together, somebody would be pushing, so
you'd need many XYZs in your spool even if you want to support only
the "clone" case.
So in the real life, I think that the exchange needs to be more
like this:
C: I need a packfile with this want/have
... C/S negotiate what "have"s are common ...
S: Sorry, but our negitiation indicates that you are way too
behind. I'll send you a packfile that brings you up to a
slightly older set of "want", so pretend that you asked for
these slightly older "want"s instead. The opaque id of that
packfile is XYZ. After getting XYZ, come back to me with
your original set of "want"s. You would give me more recent
"have" in that request.
... connection interrupted ...
C: It's me again. I have up to byte N of pack XYZ
S: OK, resuming (or: I do not have it anymore, start from scratch)
... after 0 or more iterations C fully receives and digests XYZ ...
and then the above will iterate until the server does not have to
say "Sorry but you are way too behind" and returns a packfile
without having to tweak the "want".
That way, you can limit the number of XYZ you would need to keep to
a reasonable number.
The recent proposal by Jonathan Tan also allows the server side to
tweak the final tips the client receives after the protocol exchange
started. I suspect the above two will become related.
next prev parent reply other threads:[~2017-02-01 18:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 0:48 [ANNOUNCE] Git Merge Contributor Summit topic planning Jeff King
2017-01-31 0:59 ` Jeff King
2017-02-01 19:51 ` Christian Couder
2017-02-01 9:32 ` Erik van Zijst
2017-02-01 14:53 ` Jeff King
2017-02-01 18:06 ` Junio C Hamano [this message]
2017-02-01 21:28 ` Jeff King
2017-02-01 21:35 ` Junio C Hamano
2017-02-01 20:37 ` Stefan Beller
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh94dpyzs.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=erik.van.zijst@gmail.com \
--cc=git@vger.kernel.org \
--cc=mheemskerk@atlassian.com \
--cc=peff@peff.net \
--cc=ssaasen@atlassian.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.