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.
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.
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.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=901024
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
