reminder: fx-team is the new (front-end) inbound

Ehsan Akhgari ehsan.akhgari at gmail.com
Fri Aug 2 19:30:57 UTC 2013


On 2013-08-02 1:47 PM, Gregory Szorc wrote:
> On 8/2/13 8:54 AM, Ehsan Akhgari wrote:
>> On 2013-08-02 11:17 AM, Matt Brubeck wrote:
>>> On 8/2/2013 6:56 AM, Gijs Kruitbosch wrote:
>>>> And can I add something to that... We just had some sheriffs in
>>>> #fx-team on IRC who asked for help with some conflicts in merging m-c
>>>> (which had just had inbound merged in) to fx-team.
>>>>
>>>> When doing the merge, I noticed that some people (who shall remain
>>>> nameless to protect the guilty) had pushed to both fx-team and m-i
>>>> within ~1 day of each other, with conflicting patches.
>>> In case this was the Metro team (I'm not certain it was), I'm sorry --
>>> we just made the switch from inbound to fx-team yesterday, so we may
>>> well have had patches outstanding on inbound at the time.  We probably
>>> should have checked whether there were any pending merges that might
>>> lead to conflicts.
>>
>> Merge conflicts will definitely happen more in the future, I don't think
>> it's reasonable to expect everybody to have a mapping of what they (or
>> others) have landed in which branch all the time.
>
> Detecting code merge conflicts can be automated. Whether it can be done
> so in a manner that is efficient for everyone to continuously run
> remains to be seen.

Detecting merge conflicts can only be usefully performed when attempting 
a merge, since before that you won't know what the two sides of merge 
will look like (i.e., a conflicting patch may be backed out before the 
merge happens.)

> One of the benefits of having a unified repository is that clients will
> possess all of this information locally and thus will more easily be
> able to identify merge conflicts.

When you're merging, the merge parents have to be in your local repo 
anyway, so a unified repo wouldn't be particularly helpful here.

> I've filed a bug [1] against my mozext Mercurial extension to track
> implementing merge conflict detection. I'm optimistic it will be
> possible to detect at push/pull time. Worst case we can operate a
> service/command that the sheriffs or anyone can use to detect merge
> conflicts early, before things blow up at merge time.

Hrm, what's wrong with just running hg merge?  :-)



More information about the firefox-dev mailing list