From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Shawn Pearce <spearce@spearce.org>
Cc: Alexander Miseler <alexander@miseler.de>,
Ilari Liusvaara <ilari.liusvaara@elisanet.fi>,
Jeff King <peff@peff.net>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Jens Lehmann <Jens.Lehmann@web.de>,
Christian Couder <chriscool@tuxfamily.org>,
Thomas Rast <trast@student.ethz.ch>, git <git@vger.kernel.org>,
Pranav Ravichandran <prp.1111@gmail.com>
Subject: Re: GSoC resumable clone
Date: Fri, 11 Mar 2011 22:42:35 +0700 [thread overview]
Message-ID: <AANLkTinDBm-Q3MA62r_TRqt-qxmPuDKPACr4bEPnJ6vz@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinrgqLhZK=fQ_+gUanT-zy9Mcbw-y3o7nYV9A-m@mail.gmail.com>
On Fri, Mar 11, 2011 at 10:17 PM, Shawn Pearce <spearce@spearce.org> wrote:
> I think the cached bundle idea is horrifically stupid in the face of
> the subsequent cached pack idea. JGit already implements cached packs,
> and it works very well. The feature just needs to be back-ported to
> builtin/pack-objects.c, along with some minor edits to my RFC patch to
> git-repack.sh to be able to construct the cached pack.
> ...
I wonder why I missed it. Probably to recent and has not be carved to
my mind yet.
> Junio and I would like see narrow checkout code re-implemented to
> support obtaining only a subset of the paths from the remote.
I'm close to finishing negative pathspecs (for extending narrow
clones). I'll get there.
> Once that is implemented, a client on a really bad network connection
> could do a resumable clone by grabbing a shallow clone of depth 1
> along no paths, partition the root tree up, then extend its paths
> grabbing subdirectories until the root commit is fully expanded. Then
> it can walk back increasing its depth until it runs into the cached
> pack... where it can then do byte range requests.
Yes. But then it'll cost server's processing power more. Partitioning
by path reduces chances of reusing deltas a lot.
--
Duy
prev parent reply other threads:[~2011-03-11 15:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 15:17 GSoC resumable clone Shawn Pearce
2011-03-11 15:37 ` Jeff King
2011-03-11 15:41 ` Shawn Pearce
2011-03-11 15:48 ` Jeff King
2011-03-11 20:50 ` Ilari Liusvaara
2011-03-11 21:43 ` Jeff King
2011-03-11 15:42 ` Nguyen Thai Ngoc Duy [this message]
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=AANLkTinDBm-Q3MA62r_TRqt-qxmPuDKPACr4bEPnJ6vz@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=alexander@miseler.de \
--cc=artagnon@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
--cc=prp.1111@gmail.com \
--cc=spearce@spearce.org \
--cc=trast@student.ethz.ch \
/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 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 NNTP newsgroup(s).