Re: Incorrect merge

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Almost every change on emacs-23 is intended to trunk too. Right now
 > those changes that are exclusive to emacs-23 must be flagged
 > somehow. Adding common-fixes just means that people working on emacs-23
 > will work on common-fixes, except for those cases where they would flag
 > the change as belonging to emacs-23 only. Not so hard, IMO.

Good luck to you in convincing the Emacs community, then.

 > > Even for frequent contributors who help with porting patches back and
 > > forth between the branches, this requires more thinking about where
 > > you should do the work.
 > 
 > Uh? With common-fixes you merge the commits there into emacs-23 and
 > trunk. That's all.

No, you have to choose whether to work in -23, trunk, or common-fixes.
This involves checking whether the bug affects both or not, and
whether the fix is the same.  Often trivial, but not always.

And what if you fix a bug in trunk, and only later realize it needs to
be backported?

Certainly, this is to some extent balanced by the extra work of
flagging -23 changes that shouldn't go into trunk.  The advantage of
the svnmerge-py workflow is that you make these decisions later, after
the work is done.

 > You are missing the point. common-fixes will eliminate the need for
 > cherry-picking (and for examining each commit on emacs-23 before merging
 > into trunk). The maintainers save time and the VC history is consistent
 > (with commits maintaining its identity on the branches where they are
 > installed)

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.  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.  This is probably a mildly bad thing;
work on the trunk is generally going to be more complex, and you'd
like people to concentrate there.

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).  I don't think there's any saving, and in fact the
decision to work on common-fixes (before you have a patch) is probably
harder than the decision to merge to trunk or not (with the work
complete).  To some extent that decision needs to be made before doing
any work, which increases the burden and the likelihood of a mistake.

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.
And it requires everybody to adapt a new workflow at all phases of
their work, instead of concentrating on the cherry pick only in the
cases where it's needed.