<div dir="ltr">On Sat, Aug 3, 2013 at 9:44 PM, Gregory Szorc <span dir="ltr"><<a href="mailto:gps@mozilla.com" target="_blank">gps@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">On 8/2/2013 12:30 PM, Ehsan Akhgari wrote:<br>
> On 2013-08-02 1:47 PM, Gregory Szorc wrote:<br>
</div><div class="im">>>> Merge conflicts will definitely happen more in the future, I don't think<br>
>>> it's reasonable to expect everybody to have a mapping of what they (or<br>
>>> others) have landed in which branch all the time.<br>
>><br>
>> Detecting code merge conflicts can be automated. Whether it can be done<br>
>> so in a manner that is efficient for everyone to continuously run<br>
>> remains to be seen.<br>
><br>
> Detecting merge conflicts can only be usefully performed when attempting<br>
> a merge, since before that you won't know what the two sides of merge<br>
> will look like (i.e., a conflicting patch may be backed out before the<br>
> merge happens.)<br>
<br>
</div>I think assuming the tip of an integration branch merged into central's<br>
tip is a useful approximation of a future merge. If a patch lands in an<br>
integration repository, it will eventually make its way into central, no?<br><div class="im"></div></blockquote><div><br></div><div>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.<br>

<br></div><div>(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.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
>> One of the benefits of having a unified repository is that clients will<br>
>> possess all of this information locally and thus will more easily be<br>
>> able to identify merge conflicts.<br>
><br>
> When you're merging, the merge parents have to be in your local repo<br>
> anyway, so a unified repo wouldn't be particularly helpful here.<br>
<br>
</div>Kinda sorta. A benefit of a unified repo is that changesets can be known<br>
sooner (since changesets can be pulled in before merge time). This would<br>
allow merge conflicts to be detected earlier.<br><div class="im"></div></blockquote><div><br></div><div>See above -- knowing about conflicts sooner is not always useful!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
>> I've filed a bug [1] against my mozext Mercurial extension to track<br>
>> implementing merge conflict detection. I'm optimistic it will be<br>
>> possible to detect at push/pull time. Worst case we can operate a<br>
>> service/command that the sheriffs or anyone can use to detect merge<br>
>> conflicts early, before things blow up at merge time.<br>
><br>
> Hrm, what's wrong with just running hg merge?  :-)<br>
<br>
</div>Nothing. However, I think the earlier everyone is aware of future merge<br>
conflicts the better.</blockquote><div><br></div><div>See above.  I don't think we should assume this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Currently, merge conflicts aren't detected<br>
until... merge time. This results in fire drills and/or tree closures,<br>
which can impact a bunch of people and hinder productivity.<br></blockquote><div><br></div><div>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 conflict.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think it would be useful if people were made aware of future conflicts<br>
as early as possible, before it became an issue. I imagine sheriffs<br>
would want to know if fx-team and inbound will fail to merge into<br>
central so they can alert the conflicting patch developers before tree<br>
closures occur.</blockquote><div><br></div><div>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.<br>

<br></div><div>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.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, if I were working on a patch that wouldn't merge<br>
cleanly on inbound, I think I'd like to know about that ASAP, preferably<br>
at qref time. Otherwise, I may go through an extra review cycle in order<br>
to resolve merge conflicts.<br></blockquote><div><br></div><div>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.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my ideal world, our tools would be smart enough to alert developers<br>
to possibly conflicting changes others are making.</blockquote><div><br></div><div>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.)<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For example, if you<br>
are touching file X and I have a try push touching file X, the tools<br>
would be like "hey, did you know gps is touching file X in bug 123456?<br>
[you might want to see what he's up to!]." I believe this would result<br>
in less overall developer effort due to fewer conflicting changes. I<br>
view early merge conflict detection as a step towards this ideal since<br>
it would enable patch authors to detect conflicts against expected<br>
future merges.<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br clear="all"></div><div class="gmail_extra"><div>--<br>Ehsan<br><<a href="http://ehsanakhgari.org/">http://ehsanakhgari.org/</a>></div><br>

</div></div>