cc-rework, final steps

Gregory Szorc gregory.szorc at gmail.com
Thu Jul 18 19:13:56 UTC 2013


On 7/17/13 10:03 PM, Joshua Cranmer 🐧 wrote:
> E. Merge the comm-central checkout code into mozilla-central's client.py.
> $ hg clone http://hg.mozilla.org/mozilla-central mozilla
> $ cd mozilla && python client.py checkout-comm
>
> This would require some approval from mozilla-central's build peers, and
> the current use of mozilla-central's client.py is largely to update
> external repositories that are checked into mozilla-central like NSS,
> NSPR, etc. However, I do not think it would be difficult to get such
> approval for this action, and this has roughly minimal changes from the
> current workflow for obtaining or updating the build tree.

 From a purist perspective, it would be nice to have complete separation 
and a generic solution that scales to one-offs. i.e. no references to 
c-c in m-c.

> F. Like E, but use mach instead
> $ hg clone http://hg.mozilla.org/mozilla-central mozilla
> $ cd mozilla && ./mach checkout-comm
>
> ... Unless build peers would rather I use mach instead of client.py.
> Since releng currently uses client.py to prepare source copies for
> building, this would be the first use of mach in production releng that
> I am aware of, and I don't know how much I trust throwing that switch
> right now.

If we were writing client.py today, we'd likely write it as a mach 
command. This reminds me, I want to move it out of the root directory 
because IMO its presence in m-c just confused people (since only a 
minority of developers there use it).

I would throw out a separate option: merge mozilla-central's Mercurial 
repository into comm-central. Conceptually, you start with a Mercurial 
repository with a /comm directory. Then, you transplant/graft/rebase 
mozilla-central's changesets into / of that new repository. Put another 
way, you start with m-c then rebase comm-central's commits into /comm. I 
/think/ I've seen a specialized Mercurial extension that does this type 
of repository "merging." If it doesn't exist, it should be simple enough 
to hack together with existing extensions like transplant and graft.

With this approach, you maintain a 99% clone of m-c. However, you have 
the flexibility to modify client.py, mach, etc as you see fit. There is 
the potential for "merge conflicts," sure. But if things are done right, 
those should be few and far between.



More information about the tb-planning mailing list