On 05/31/2014 12:38 PM, Chad wrote: > On Sat, May 31, 2014 at 5:52 AM, Bartosz Dziewoński <matma....@gmail.com> > wrote: > >> I don't like this idea, for the same reasons that other have already >> given. Grafting histories with git-replace might be viable, but it'd still >> be clunky and non-intuitive. >> >> > Ok, fair enough. Everyone's made some really good points so let's drop the > idea of dropping our history. > > However I think we should continue to discuss ways to contain the repo size > going forward. That, combined with some aggressive repacking and dropping > of refs/changes/* (when we move to Phabricator) should help get it under > control. > > >> Why don't we just suggest that people use shallow clones? Git supports >> pushing from and pulling to them since 1.9, and while Gerrit doesn't accept >> pushes from them (or at least it didn't when I just tried), I see no reason >> why Phabricator would have any issues if it only works on diffs anyway, not >> commits. > > > This is also a good idea. > > -Chad
Chad, thanks for bringing this up. I'm especially grateful that you named the target repo size at 30 to 35 MB -- it makes this more concrete. I think some more numbers/facts might help us make the right tradeoffs here to think about ways to contain the repo size going forward -- like: * Antoine said "My repacked copy of core is 270MB" and we have some disagreement about whether that's okay. Is there a max size we want to avoid getting to? * A bigger repo is obviously slower to download in full; is it also slower to search or otherwise work with? How much slower? Most of our developers are probably not on SSDs yet. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
