Re: GSoC resumable clone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 11, 2011 at 10:17 PM, Shawn Pearce <spearce@xxxxxxxxxxx> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]