Re: Incorrect merge

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Adding an extra branch does not increase the current workload.

Of course it does.  Most occasional developers work only on the branch
that they use every day, either trunk or stable/maintenance.  That's
where they test, that's where they refine.  Adding the common-fixes
branch means they need to clone and maintain that branch, and work in
a branch that they don't use.

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.

 > They would commit to common-fixes the same way they do for emacs-23.

You mean, stuff that doesn't belong there, as started this thread? ;-)

 > If the set of people who don't want to learn determines how the project
 > is managed,

It already has, in both the choice of BTS and the choice of dVCS.  In
the sense that in both cases the ability to continue with basically
the same flow, even if implemented with slightly different commands,
was a crucial requirement in choice of software.

 > And I think that you'll find quite harder to implement it on bzr
 > than on SVN.

Depends on what you mean.  The basic functionality we're talking about
here, blocking certain revisions from being merged or cherry-picked,
depends on a globally unique revision ID.  In a centralized system,
there's only one authority, so there's no problem.  In a dVCS you have
to contrive one, but all the dVCSes have one.  So I don't think it's
any harder in this sense.

On the other hand, this can really only be enforced at push time.  So
a developer could make several commits in a branch that is blocked
from merging before realizing it.  That would be inconvenient, and
it's not obvious to me how to work around.  But I don't think it would
be more than an inconvenience.

Finally, although right now Emacs doesn't have the skills AFAIK, in
the long run implementing for Bazaar might be far more powerful since
the script could be adapted from svnmerge.py, written in Python, and
thus have direct access to Bazaar's internal information.  Maybe even
as a plugin.

 > It is quite pathetic to even consider using hacks that workaround
 > the limitations of simplistic VCS like svn

Call it what you like; however, the fact is that Emacs has chosen to
use a workflow that emphasizes Bazaar's ability to work like a
centralized system.  Individual developers can use the decentralized
features as they like, but the project workflow does not mandate them.

 > when there are standard practices on dVCS for properly solving the
 > problem at hand.

But there aren't.  Only Darcs supports cherry-picking properly.  And
as an add-on hack, svnmerge.py does.  The revision-oriented systems
don't implement the necessary accounting.  What is available for the
revision-oriented dVCSes is a set of workflows that *mostly* avoid
creating a problem, but have their own inconveniences.

I suspect the Emacs community will prefer to implement a tool that
codifies their workflow and adds certain features such as true
cherry-picking and blocking revisions, to changing the workflow.