[Kde-scm-interest] Have we arrived to a dead end?
chanika at gmail.com
Wed Feb 17 22:13:17 CET 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100217/26340def/attachment.sig
More information about the Kde-scm-interest