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

Ben Bucksch ben.bucksch at beonex.com
Thu Dec 17 16:44:10 UTC 2015

Joshua Cranmer 🐧 wrote on 17.12.2015 02:59:
> The build team has been more or less promising a build system blitz of 
> changes in Q1 2016 to finally move to a saner build system, and the 
> current c-c/m-c repository directory structure is a difficult 
> roadblock to those changes.

Fair enough

> it's not feasible for us to not use Mozilla's build system, so long as 
> we have substantial C++ code that needs to interact with Gecko 
> internals, and anyone who thinks otherwise is misinformed.


> 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/ .

For the build system, that would be strictly identical to a merged repo.

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/ .

> forking mozilla-central and periodically merging new revisions into 
> mozilla-central

I would be concerned about that, due to repository size. m-c is 20 times 
larger than c-c.

> 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.


More information about the tb-planning mailing list