On Wed, Dec 18, 2019 at 1:17 PM Joseph Myers <jos...@codesourcery.com> wrote:
> On Wed, 18 Dec 2019, Jason Merrill wrote: > > > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers <jos...@codesourcery.com> > > wrote: > > > > > Points for consideration: > > > > > > 1. Do we want some kind of rearrangement of refs as in the 1b > > > repository or not? > > > > > > > Maybe? How much space does that save in a clone? How much work does a > > partial clone add on the server, since the server needs to pack up the > > objects for the partial clone rather than just transmitting its own > packs? > > I haven't measured work on the server, and timing individual clones is > liable to a lot of variation from variable load there, but for a single > clone --mirror of the 1b repository (so all refs, including refs/deleted/) > I got > > real 13m16.473s > user 16m45.429s > sys 0m33.901s > > and 1360 MB objects directory, but for a clone without --mirror (so only a > limited subset of refs and the server needing to build a pack) > > real 15m5.554s > user 12m11.771s > sys 0m26.914s > > and 950 MB objects directory. Adding the objects from the existing > git-svn mirror (presumably also under refs not fetched by default) > increases repository size by about 300 MB, based on a previous test of > doing that (most blob and tree objects will be shared between the two > versions of the history, but all the commit objects are separate). > So a 30% space savings; that's pretty significant. Though I wonder how much of that is refs/dead and refs/deleted, which seem unnecessary to carry over to git at all. I wonder if it would make sense to put them in a separate repository that refers to the main gcc.git? Jason
