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

Ehsan Akhgari ehsan.akhgari at
Thu Aug 8 02:19:04 UTC 2013

On Sat, Aug 3, 2013 at 9:44 PM, Gregory Szorc <gps at> wrote:

> On 8/2/2013 12:30 PM, Ehsan Akhgari wrote:
> > On 2013-08-02 1:47 PM, Gregory Szorc wrote:
> >>> 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.)
> I think assuming the tip of an integration branch merged into central's
> tip is a useful approximation of a future merge. If a patch lands in an
> integration repository, it will eventually make its way into central, no?

No, because it might get backed out.  Let me try to construct a scenario,
let's say that I land A on inbound and you land B on central.  Let's assume
that if you try to merge A and B right at this point, you'll get a
conflict.  Then, your tool would scream at both of us.  Then let's say that
my patch burns the tree, and I get backed out by A' (the reverse patch,
almost).  Now if you try to merge inbound and central, you don't get a
conflict.  If you do a bidirectional merge at this point, I'll get a
conflict the next time I try to rebase A on top of the merged tree.  Now
fixing the conflict is my problem, not anybody else's.  In this scenario,
the warning generated by your tool will be misleading.

(Note that I could also extend this example by somebody landing C on top of
B which conflicts in different ways with A, and so on.)

>  >> 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.
> Kinda sorta. A benefit of a unified repo is that changesets can be known
> sooner (since changesets can be pulled in before merge time). This would
> allow merge conflicts to be detected earlier.

See above -- knowing about conflicts sooner is not always useful!

>  >> 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?  :-)
> Nothing. However, I think the earlier everyone is aware of future merge
> conflicts the better.

See above.  I don't think we should assume this.

> Currently, merge conflicts aren't detected
> until... merge time. This results in fire drills and/or tree closures,
> which can impact a bunch of people and hinder productivity.

The reason why this is a problem though is what Gijs mentioned (I'll reply
to that separately.)  It has nothing to do with *when* we detect the merge

> I think it would be useful if people were made aware of future conflicts
> as early as possible, before it became an issue. I imagine sheriffs
> would want to know if fx-team and inbound will fail to merge into
> central so they can alert the conflicting patch developers before tree
> closures occur.

Tree closures will only occur when the merge happens successfully at the
source code level but the semantics of the merged code is now wrong.  There
is no automated tool which we can write that would be able to detect that
scenario without building and testing our code.

For the case where the merge conflict is detected at the source code level,
Mercurial will refuse to complete the merge locally, so there is no risk of
tree closures there, and then we'll be talking about the problem Gijs
brought up.

> Also, if I were working on a patch that wouldn't merge
> cleanly on inbound, I think I'd like to know about that ASAP, preferably
> at qref time. Otherwise, I may go through an extra review cycle in order
> to resolve merge conflicts.

Resolving merge conflicts will typically be handled by somebody else, so
you would only need to deal with the additional review round if that merge
happens unsuccessfully.

> In my ideal world, our tools would be smart enough to alert developers
> to possibly conflicting changes others are making.

This should be the default in any distributed development environment.
(i.e. you should always assume that your work will conflict with the work
done on other branches.)

> For example, if you
> are touching file X and I have a try push touching file X, the tools
> would be like "hey, did you know gps is touching file X in bug 123456?
> [you might want to see what he's up to!]." I believe this would result
> in less overall developer effort due to fewer conflicting changes. I
> view early merge conflict detection as a step towards this ideal since
> it would enable patch authors to detect conflicts against expected
> future merges.

This would actually be pretty bad.  I won't care about most of the work
being done by people on the same files that I touched.  The entire DVCS
merge model is based on top of this fundamental assumption, and that is
true in the majority of cases.  It would be extremely irritating for there
to be a tool which notifies me about every time somebody else touches a
file that I've touched.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list