Re: GSoC resumable clone

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Mar 11, 2011, 15:42 UTC
Message-ID: <AANLkTinDBm-Q3MA62r_TRqt-qxmPuDKPACr4bEPnJ6vz@mail.gmail.com>
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:

Show 6 quoted lines

> 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.

Show 6 quoted lines

> 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