Strategies for push/merge problem?

[Jason Orendorff]

On Mon, Jul 14, 2008 at 2:17 PM, Johannes Stezenbach <js at sig21.net> wrote:
> On Mon, Jul 14, 2008 at 12:24:13PM +0200, Roman Kennke wrote:
>>
>> Also: I know that the centralized approach is not the most HG-ish way to
>> work with HG. But I also think that a lot of people are using it that
>> way, and it shouldn't be so difficult to do. One nice thing about HG is
>> its flexibility, but this needs to be easier.
>
> I happend to come across the Mozilla site recently, maybe
> it is of interest because Mozilla is a largish project:
>
> http://developer.mozilla.org/en/docs/Mercurial_FAQ#Push_to_the_central_repository
>
> It would be interesting to hear how this works out in practise
> for the Mozilla team. If someone finds out please let us know.

We've been using Mercurial in this centralized way for a while now,
and yes, this pull-update-commit-merge race condition is a pain,
especially given the volume of check-ins.  We've started discussing
how to fix this.  It's sure to be a hot topic at the Firefox summit at
the end of this month.

One possibility that has come up was to have an automated system that
continually polls certain public repositories (perhaps the Mozilla
module owners would have public "outgoing" repositories) and
automatically pulls, merges, builds, and tests new heads as they
appear (whenever automatic merging is possible).  Only revisions that
pass tests would be pushed to the system's own public repo, which
could be the official trunk.  I don't know that anyone has actually
thought this through or decided to do it "soon" though.

In the short term, we're still working on finding ways to make a
highly mergeful changelog readable and navigable.

-- 
Jason