Jesus Cea wrote:
> On 03/02/11 13:04, Nick Coghlan wrote:
>> On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea <j...@jcea.es> wrote:
>>> In fact, "up-porting" is usually better, because you don't have to think
>>> if you must downport or not. Versión "n+1" is always a superset of
>>> versión "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge.
>
>> As I said, I'm happy to roll with the proposed workflow as documented
>> in the PEP, based on the advice from experts that Mercurial doesn't
>> really suit our current work flow. I'm just noting that I expect the
>> result will be fewer fixes in maintenance branches, since it is harder
>> to divide the tasks of implementing a fix for the main line of
>> development and applying that fix to the maintenance branches (unlike
>> the way it often happens now).
>
> The problem now is that patches in the development branch are
> "forgotten" and not backported when appropiate, and nobody cares about
> "blocking" versions to "not backport". Now running "svnmerge" to do a
> real merge is very risky, because the "blocking" is not actually
> maintained. People uses "svnmerge" backporting patch by patch, manually.
> Automatic mode is a disaster, because nobody cares about "blocking" in
> "svnmerge".
What's wrong about manually using svnmerge to backport those
things that you actually do want to backport, rather than
automatically merging back changes that you don't want to be
backported ?
Note that blocking checkins from backports to certain branches
adds more work to the developers, than simply not relying on
automatic merges at all. The reason is that many new features
will not get backported, only fixes to problems will.
> If we up-port, no patch is forgotten. The rule should be: "patches in
> n+1 are a SUPERSET of patches in n". With this rule, mercurial takes
> care of everything (a patch in n+1 can 'undo' a patch up-ported from n,
> if needed, keeping the rule).
Mercurial is still a mystery to me, so please bare with me...
Is there a technical requirement for having to use this workflow:
1) Patch -> Branch 3.1 -> Branch 3.2 -> Mainline
Why can't we use our current workflow:
2) Patch -> Mainline (optionally) -> Branch 3.2
(optionally) -> Branch 3.1
Or perhaps a slightly modified one (if it suits Mercurial better):
3) Patch -> Mainline (optionally) -> Branch 3.2 (optionally) -> Branch 3.1
(Legend to the diagrams: "->" means "merge patch into")
Note that 2) could just as well be done like this:
2) Patch -> Mainline (optionally) -> Branch 3.1
(optionally) -> Branch 3.2
i.e. the order of the backports doesn't matter.
I don't understand why the developers have to follow the tools and
not the tools the developers. If a tool doesn't fit, it's the wrong
tool, IMHO, unless there are good reasons for changing you workflow
because it allows the *workflow* to improve (rather than just permitting
you to work with a specific tool). In other words: change is good
if it improves things, not if it only changes things :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 04 2011)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
