cc-rework, final steps

Ehsan Akhgari ehsan.akhgari at gmail.com
Thu Jul 18 20:25:03 UTC 2013


On 2013-07-18 3:13 PM, Gregory Szorc wrote:
> 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.

See the discussion in bug 787208, please.

Ehsan




More information about the tb-planning mailing list