A merged comm-/mozilla-central repository is now available

ace acelists at atlas.sk
Thu Dec 17 21:59:13 UTC 2015


-------- Original Message --------
Subject: Re: A merged comm-/mozilla-central repository is now available
From: Joshua Cranmer 🐧 <pidgeot18 at gmail.com>
To: tb-planning at mozilla.org
Date: Thu, 17 Dec 2015 15:47:05 -0600

>>>> I would be concerned about that, due to repository size. m-c is 20
>>>> times larger than c-c.
>>> Why is this a concern? Instead of pulling c-c, then m-c, you pull just
>>> c-c which includes m-c.
>>
>> Right. But m-c is 20 times the size of c-c, so c-c is then 20 times
>> larger. The repo is the crown perls of the project.
>>
>> I don't care much about the download size (that's the same either
>> way), I care about the repo size, because it's the repo that you need
>> to work with when you diff, backup etc.pp..
> 
> You do realize that, no matter what, you have to have m-c on-disk
> anyways if you care about building? It may have been thought in 2007 and
> 2008 that it could not be the case one day, but it's been clear since
> 2011 that it is very much the case that c-c needs m-c to build and that
> is to remain the situation for quite some time.

Ben probably meant the repo size as in how many files the hg
qpop/qref/qpush commands need to parse when creating patches. And there,
doing any command on m-c is much slower than on c-c (I do it sometimes).
So I agree with Ben here. It is true that the download/on disk size is
the same, but it matters how it is partitioned into repos/logical units.



More information about the tb-planning mailing list