A merged comm-/mozilla-central repository is now available
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.
> 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
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