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

ishikawa ishikawa at yk.rim.or.jp
Tue Dec 22 09:00:35 UTC 2015


On 2015年12月17日 10:59, Joshua Cranmer 🐧 wrote:

> 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). The cypress
> repository is dedicated to testing release automation for the necessary
> changes that need to be made. Once these changes can be identified and we
> get working builds and tests on all the platform, I expect that we will have
> a day where we perform the merge and push to comm-central. I'm using bug
> 787208 to track this change.

Thank you again for the great work.

I re-read the bug 787208 and I realized that, (sorry for catching up very
slowly), that
the main opposition seemed to be that by having the C-C directory
at the same level of M-C, it was feared that the C-C directory has to be
merged completely into the same HG repository.

Was this intended?


I wonder what the structure of the repository (or repositories) under cypress.
Do you intend to put C-C and M-C into the same repository?

Background of my question:

After having to work with C-C and M-C dichotomy for several years (OK, maybe
a few years),
I thought it was not intended but the intention was simply having the
C-C directory to be maintained at the same directory position of other
modules in M-C and
still have the different HG repositories.

Even this level of integration would make things much simpler in terms of
BUILD system integration, I think, by simply looking at the bustages of
build: the contortion of having to reference mozilla module subdirectories
under ./mozilla/modulename instead of simple ./modulename has caused many
failures in the past few years.

I think most of the recent build-related bustages are due these pathname
issues, ugh.

But then the MAIN opposition in bug 787208 seemed to be the
INCLUSION of C-C into M-C hg repository.
I didn't catch this subtle difference until now.

I wonder how many of C-C patch contributors want to have a single gigantic
repository instead of separate repositories.

Having the source code directory in the same directory position as those of
other modules in  M-C is a good idea.
Then, we can simply address the mozilla modules by
simple ../modulename and be done with it. Right?

Having separate repositories may not be such a bad idea given the merit of
the above only,
and the separate repositories setup will make things easier in terms of the
FF push
not triggering automatic build of C-C or vice versa.
(I am not familiar how to set up such IGNORE feature at the top-level of M-C.)

But I have been living with the separate repositories of M-C and C-C (and
C-C's M-C lives under
./mozilla subdirectory), merged C-C editing and pushing can be done
once we move under ./C-C.
Only hitch would be when we want to build C-C TB, then we have to figure out
how to create C-C TB on the push.
Maybe we have to tell the build infrastructure ONCE for ALL that
`mail' program ought to be built under ./C-C
and we probably need to use the infamous mozilla-* patch name convention to
force the
applying of patches under ./mozilla (i.e., the separate direcotry), this time
maybe using thunderbird-* patch convention to force applying the patches to
./C-C subdirectory (i.e., the separate C-C
repository).

Oh well. There are still many details to work out, but
the continued impact on build infrastructure, which TB needs to survive,
will be minimized greatly IMHO.
Unfortunately this point does not seem to be understood very well outside
C-C TB developer community. :-(


TIA




More information about the tb-planning mailing list