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 <nico@xxxxxxxxxxx> wrote:
On Tue, 1 Feb 2011, Shawn Pearce wrote:
On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> 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