On Sat, Feb 23, 2008 at 03:23:49AM +0100, J.C. Pizarro wrote: > On 2008/2/23, Al Viro <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote: > > > Al Viro <[EMAIL PROTECTED]> writes: > > > > > > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote: > > > > > > > >> >do you tend to clone the entire repository repeatedly into a series > > > >> >of separate working directories > > > >> > > > >> Too time consuming on consumer drives with projects the size of Linux. > > > > > > > > git clone -l -s > > > > > > > > is not particulary slow... > > > > > > How big is a checkout of a single revision of kernel these days, > > > compared to a well-packed history since v2.6.12-rc2? > > > > > > The cost of writing out the work tree files isn't ignorable and > > > probably more than writing out the repository data (which -s > > > saves for you). > > > > > > Depends... I'm using ext2 for that and noatime everywhere, so that might > > change the picture, but IME it's fast enough... As for the size, it gets > > to ~320Mb on disk, which is comparable to the pack size (~240-odd Mb). > > Yesterday, i had git cloned git://foo.com/bar.git ( 777 MiB ) > Today, i've git cloned git://foo.com/bar.git ( 779 MiB ) > > Both repos are different binaries , and i used 777 MiB + 779 MiB = 1556 MiB > of bandwidth in two days. It's much! > > Why don't we implement "binary delta between old git repo and recent git repo" > with "SHA1 built git repo verifier"? > > Suppose the size cost of this binary delta is e.g. around 52 MiB instead of > 2 MiB due to numerous mismatching of binary parts, then the bandwidth > in two days will be 777 MiB + 52 MiB = 829 MiB instead of 1556 MiB. > > Unfortunately, this "binary delta of repos" is not implemented yet :|
See git-pull . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
