[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect merge

From: Stephen J. Turnbull
Subject: Re: Incorrect merge
Date: Wed, 03 Nov 2010 14:22:22 +0900

Óscar Fuentes writes:

 > > And what if you fix a bug in trunk, and only later realize it needs to
 > > be backported?
 > And how is this different from the current workflow?

It's not.  That's precisely my point.  You can reduce cherry-picking,
but not eliminate it.

 > Right now people
 > must decide the scope of the patch. Adding the common-fixes branch
 > simplifies the task from the conceptual POV: instead of
 >  * commit fixes for emacs-23 and trunk into emacs-23
 >  * commit fixes intended for trunk only into trunk.
 >  * commit fixes intented for emacs-23 only into emacs-23, put something
 >   into the log message and hope it is noticed.

But the svnmerge.py workflow does a lot better than that; as long as
people use svnmerge.py, it does the accounting.  People grumble about
changing tools, but the workflow will be very similar; they'll get
over it quickly.  Changing the workflow is more effort, takes longer,
and some people will never get over it.

 > you have
 >  * commit fixes for emacs-23 and trunk into common-fixes.
 >  * commit fixes intended for emacs-23 only into emacs-23.
 >  * same for trunk.

You're counting bzr-level tasks, but my point is that these tasks are
more complex/difficult than the corresponding tasks in the other
workflow because the decisions are made in advance of any commit,
rather than with the actual commit to look at.

 > > It doesn't eliminate the need for cherry-picking as long as there's
 > > more than one active branch: you can make a mistake about where to
 > > work.
 > If you come with "yes, but someone can make a mistake..." then any
 > schema we can think of can be dismissed with the same reasoning.

I'm not dismissing your scheme yet.  I'm saying your accounting is way
too optimistic.

 > >  This should be a lot less frequent in the common-fixes
 > > workflow.  It does require people who would otherwise focus on trunk
 > > to switch between branches, and to be continuously thinking about
 > > which branch they should be in.
 > Again, the current workflow requires people to decide that.

Again you ignore the point, which is that the current workflow means
looking at an existing commit and making a decision.  The commit-fixes
workflow involves thinking about a prospective patch and making a
decision where to produce it, or creating yet another branch and
looking at the commit there.

Creating a temporary branch just for that fix is precisely what I do
with git, but doing that in Bazaar or Mercurial is too expensive for

 > > Every commit on common-fixes needs to be examined before making it to
 > > be sure that it's appropriate for both release branches (common-fixes
 > > is never released).
 > If you want a fool-proof method, propose a gatekeeper workflow (with
 > several layers of verification, for enhanced security :-)

You're missing the point yet again.

 > > The VC history is consistent, but I don't think the maintainers save
 > > much time and it's at a higher burden to the general contributors.
 > The consistency on VC history is a huge win for me. The ability to
 > quickly decide which branches contain a given commit will turn more and
 > more important as feature branches proliferate.

I don't agree; feature branches will branch from trunk, synch to it,
and eventually merge to it, being entirely unconcerned with what is or
is not in the maintenance branch or common-fixes, and vice-versa.
That's really the point of having a separate maintenance branch.

 > Right now we should put the revision id (not revision number) of a
 > fix on the respective bug report when closing it.
 > > And it requires everybody to adapt a new workflow at all phases of
 > > their work,
 > This is an exaggeration. Only people who work on emacs-23 would need to
 > adapt their workflow (committing to common-fixes instead of
 > emacs-23).

But that requires examining the commits of trunk-only workers for -23
relevance, and cherry-picking if they are relevant.  You can't have it
both ways.  Either you're serious about consistent history and
avoiding cherry-picking as much as possible, which requires everybody
to consider whether their fixes are -23 relevant, or you're not.

True, people working only on features can avoid this.

 > Doing the cherry-picking (with the current workflow) or the merge (with
 > my proposed branch) is something that only a few maintainers should care
 > about.

Doing it is Bazaar's problem; if Bazaar doesn't make that work as
convenient as possible, we made a big mistake.  The question is which
way is harder to think about.  Your way requires all committers who
fix bugs to worry about which branch to commit to.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]