Re: Incorrect merge

[Óscar Fuentes]

"Stephen J. Turnbull" <address@hidden> writes:

>  > The *only* way? What abut having a branch for that purpose?
>
> Having a branch doesn't mean that people will use it properly.

They need to learn and remember how to insert the necessary
meta-information needed by the script.

> Most people do not understand branching and merging, or how to
> analyze workflows, and don't want to learn.  Having a script allows
> them to participate without learning.

Adding an extra branch does not increase the current workload. They
would commit to common-fixes the same way they do for emacs-23. The only
"new" thing to learn is that there is a branch for those changes shared
by emacs-23 and trunk, which is a concept quite easy to grasp. This
seems to me more clear than having to remember how to include some
magical spell on the commit message.

If the set of people who don't want to learn determines how the project
is managed, the most sensible way is to revert to CVS or even to
something more primitive.

>  > BTW, do you realize that the script would end cherry-picking
>  > commits
>
> Not at all.  The whole point of svnmerge.py is to support
> cherry-picking in SVN, as Python has up to 6 active mainlines at any
> given time, along with sandbox branches of varying longevity and
> proximity to a mainline.  Sure, that requires a fairly high level of
> understanding and effort on the part of the script authors, but Python
> considered it worth it.
>
> It's not the only way, I'm sure, but it's one good, proven way.

I used svnmerge.py. Is a hack that only seems "good" as long as you are
desperate enough. And I think that you'll find quite harder to implement
it on bzr than on SVN.

It is quite pathetic to even consider using hacks that workaround the
limitations of simplistic VCS like svn when there are standard practices
on dVCS for properly solving the problem at hand.