A merged comm-/mozilla-central repository is now available
patrick at cloke.us
Thu Dec 17 16:53:30 UTC 2015
On 12/17/15 11:44 AM, Ben Bucksch wrote:
> Joshua Cranmer 🐧 wrote on 17.12.2015 02:59:
>> The only feasible path forward is for us to merge comm-central and
>> mozilla-central into one repository.
> There's another option that's much simpler: m-c and c-c can keep being
> different repositories, but they can live in the same directory
> on-disk. You can simply check out both repos in the same on-disk
> repository. mail/ and mailnews/ would live on the same level as
> browser/ .
This is much more complicated for people who are not experts in version
> If hg has an issue with that, because it expects e.g. a root/.hg/
> directory, then you can simply ignore/delete the m-c .hg/ dir (because
> we make almost no changes there anyway) and keep the c-c .hg/ .
How would you update the Mozilla code then? This isn't a reasonable
>> forking mozilla-central and periodically merging new revisions into
> 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. The size should be roughly equivalent (and can
be checked very easily by pulling Joshua's test repo). I don't believe
this argument without numbers to back it up.
>> Fortunately, I already have a script that can merge the two
>> repositories together into one. The resulting repository is at
>> <http://hg.mozilla.org/projects/cypress/>, and it was produced by a
>> fully-automated script that pulls comm-central, deletes the build
>> system (well, the remnants thereof, most having been gutted by
>> cc-rework quite some time ago), rewrites references to the mozilla/
>> directory to the top-level, and then pulls and merges mozilla-central
>> with an automated resolution of the two remaining conflicting files
>> (.hgtags and AUTHORS).
> I was thinking along the same lines, just that I propose that this
> happens as part of the local checkout system (client.py), instead of
> pushing m-c changes into the official c-c repo.
Doing it locally for every person seems quite inefficient and prone to
issues if conflicts ever arise. I.e. it's harder to ensure that everyone
ACTUALLY has the same code or not.
>From previously conversations with Joshua and other developers, I agree
with him that the periodic merging of m-c into c-c is the 'best' way
Great work Joshua,
More information about the tb-planning