On Tue, 1 Feb 2011, Nicolas Pitre wrote: > On Tue, 1 Feb 2011, Shawn Pearce wrote: > >> On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre wrote: >>> On Tue, 1 Feb 2011, Shawn Pearce wrote: >>> >>>> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy wrote: >>>>> Narrow/Subtree clone is still just an idea, but can pack cache support >>>>> be made to resumable initial narrow clone too? >>>> >>>> This would be very hard to do.  We could do cached packs for a popular >>>> set of path specifications (e.g. Documentation/ if documentation only >>>> editing is common), but once we start getting random requests for path >>>> specifications that we cannot predict in advance and pre-pack we'd >>>> have to fall back to the normal enumerate code path. >>> >>> Also... people interested in Narrow clones are likely to be shallow >>> clone users too, right? >> >> I think that depends. Some users might want the full history of the >> files they are working on. Others wouldn't care and just want the tip >> revision so they can make changes. Obviously a shallow clone of depth >> 1 is very cheap to implement on the server; there really isn't any >> caching required. >> >> Probably 50% want full history, 50% want shallow clone. So I doubt we >> can assume that narrow implies shallow and thus is cheap. :-( > > Let's see what happens when this gets used in the wild. also, many users may assume that a full clone is very expensive, but for code-based projects a full clone is usually comparable to the size to download a single tarball. if you have large binary files this changes, but most projects don't. David Lang