Re: Incorrect merge

[Stephen J. Turnbull]

Óscar Fuentes writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 > 
 > [snip]
 > 
 > > Your way requires all committers who fix bugs to worry about which
 > > branch to commit to.
 > 
 > Yes, exactly as it happens right now.

Which is missing the point.  One point of the svnmerge-based workflow
is that the branch to commit doesn't really matter, and the decision
to block merges/cherry-picks made after inspecting the commit.  So the
svnmerge approach is *better* in this respect.

But the main point is that cherry-picking, which is a natural workflow
in this context in general, and the historical practice of Emacs, is
well-supported by svnmerge.  The point of the common-fixes workflow is
to (unnaturally) avoid cherry-picking.  But (a) this is awkward for
the workers, especially at first, and (b) it is a change.

As I've said before, I personally use "emphemeral" branches in git for
this situation.  And I'm sure that for many communities, the common-
fixes approach works well too.  But the Python community strongly
prefers the svnmerge approach (porting svnmerge to Mercurial is one of
the blockers on their migration), and my feeling is that the Emacs
community is similar to the Python community in this respect.

I don't know about others, but you don't need to prove to me that your
approach works.  Although I haven't actually used it in practice, the
theory looks good enough.  The question I have is whether it's well-
adapted to Emacs.  So far the Emacs maintainers (including Richard)
have been *very* conservative about changes to workflow.  svnmerge (or
a port of it) *supports* the current workflow.  That's going to be
tough to beat.