reminder: fx-team is the new (front-end) inbound
ehsan.akhgari at gmail.com
Thu Aug 8 02:31:18 UTC 2013
On Sun, Aug 4, 2013 at 5:43 AM, Gijs Kruitbosch <gijskruitbosch at gmail.com>wrote:
> On Aug 2, 2013 9:31 PM, "Ehsan Akhgari" <ehsan.akhgari at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev