On Sun, Aug 4, 2013 at 5:43 AM, Gijs Kruitbosch <[email protected]>wrote:
> > On Aug 2, 2013 9:31 PM, "Ehsan Akhgari" <[email protected]> wrote: > > Hrm, what's wrong with just running hg merge? :-) > > Nothing per se, especially if there are no conflicts. > > However, it is often easier (and less likely to lead to problems) for > conflicts to be resolved by people who work on the code in question. > > Absolutely! And this is how DVCS systems are _supposed_ to be used. This is the core idea behind the "pull request" model that git supports (and the crippled github implementation of it): if you send me a pull request and that conflicts with my tree, I'll reject your pull request and make the merging/rebasing your problem. When you've fixed that, you can send me a new pull request, which is what I would want to merge. The fundamental problem here is that we've been using Mercurial similar to a centralized VCS. We currently all land code on the same branch (or on the same few branches -- inbound/b2g-inbound/etc.) and we then forget about the patch until somebody screams at us. In this model, the merge problem is not the patch author's problem, and sometimes the person doing the merge doesn't have enough confidence in fixing the conflicts, and we should not expect them to. We could switch to a different model similar to git-pull-request which shifts this burden where it belongs, but without that, there is no magic way to fix this problem, since we're asking the wrong person to deal with it. Until that happens, the only tool in the merger's toolbox is to back out one (or both) sides of the conflict -- and yes, determining the offending commit(s) can be painful and time consuming. > For instance (without wanting to specifically pick on metro, but I had to > pick an example), there were conflicting changes in the metro browser.xul > that touched the toolbar. One added a circular progress bar, one put a > bunch of the existing items in a stack for non-primary buttons or whatnot. > Deciding whether the progress meter goes before, after or inside this stack > is something best done by the people writing/reviewing these patches, > rather than whoever happens to run the relevant merge. > > I do think that when teams stick to a single branch for landings, the > frequency of merge-time conflicts can be significantly reduced. > Well, there are people who need to touch code "belonging" to other teams, and it's unreasonable to expect those people to change their workflow (and it might be impossible in the cases where they need to touch code belonging to several other teams -- in which case there would be no correct branch to push their commit to even if they were willing to disrupt their workflow.) Also, note that the number of possible merge scenarios grows exponentially on the number of branches you have, so the more trees we add, the more different possible merge combinations, and the more number of conflict scenarios. Cheers, -- Ehsan <http://ehsanakhgari.org/>
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
