Re: Incorrect merge

[Stephen J. Turnbull]

Ó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
me.

 > > 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.