On 2008/2/23, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote: > > Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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 :| - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
