On February 17, 2010 13:00:39 Oswald Buddenhagen wrote:
> On Wed, Feb 17, 2010 at 05:36:43PM +0000, John Tapsell wrote:
> > I'm not all that convinced we even need shallow clones.
> > 
> > The Gnome guys found shallow clones only saved a small amount of space:
> > 
> > The first size, in MB, is the full checkout, and second number is a
> > shallow clone of depth 1.
> > 
> > [...]
> > 
> > Hardly seems worth the complication, let alone being a blocker wish,
> > for a 10% saving.
> 
> these numbers were to be expected, as a shallow clone needs to contain
> the head revisions of all files in the tip tree. the rest is stored in
> pretty efficient xdeltas. and as most files mostly only gain code, the
> inverse deltas are small. so a project must have a rather impressive
> history to make its length contribute significantly to the repo size.
> however, things are radically different for badly compressible binary
> data, especially when files are often completely discarded - artwork.
> 
> narrow clones will be a significantly bigger gain, as *all* blobs for
> the irrelevant files are omitted, including the big tip ones, obviously.
> 
> and just in case it's not obvious: one consequence of the delta
> compression is that any file's bare presence at any point in time has a
> significantly bigger impact than another file's long history. which is
> one of the reasons why i want a clean splitting which enables moving
> without leaving behind artificts. shallow/narrow clones would
> theoretically compensate most of the problem, but i predict that in the
> end everyone who is actually using the history will end up with more or
> less complete clones sooner or later anyway.

just in case anyone's not clear on the terminology: a shallow clone is one 
that doesn't have the full history. 
a narrow clone is one that doesn't have all the files (eg. just 
kdebase/workspace/plasma instead of the whole kdebase)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest

Reply via email to