Re: GSoC resumable clone

On Fri, Mar 11, 2011 at 07:37, Jeff King [off-list ref] wrote:

On Fri, Mar 11, 2011 at 07:17:31AM -0800, Shawn O. Pearce wrote:

quoted

quoted

quoted

A simpler way to restartable clone is to facilitate bundles (Nicolas'
idea). Some glue is needed to teach git-fetch/git-daemon to use the
bundles, and git-push to automatically create bundles periodically (or
a new command that can be run from cron). I think this way fit in GSoC
scope better.

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 think there is room for both ideas. The cached bundle idea is not just
"here, download this bundle first". It is "here, download this _other
thing_ first, which might be a bundle, another git repo, a torrent,
etc".

Fair enough. Though I wouldn't limit this to bundles. Instead I would
suggest supporting any valid Git URLs, and then extend our URL syntax
to support bundles over http://, rsync://, and torrent.

So yeah, cached packs are a way better solution if you are just going to
have an extra bundle on the same machine. But that's just one use case.
The ability for my server to say "go hit kernel.org first, and then come
back to me to pick up the deltas" is also valuable. Similarly, the
ability to serve an initial bundle off a torrent is useful for extremely
large projects.

If we support any URL and don't assume the URL is a bundle, you can
point traffic at kernel.org to for example grab Linus' primary
repository first, even if he doesn't have a bundle.

-- 
Shawn.