On Sat, Mar 19, 2011 at 12:22 PM, Jesus Cea <j...@jcea.es> wrote:
> On 19/03/11 03:14, Nick Coghlan wrote:
>> (i.e. start moving towards more of a style of development where code
>> doesn't land in the main repository until it has been vetted by the
>> buildbots *first*).
Unfortunately, this is *not* good enough. Basically what you are
talking about is equivalent to automatic rebasing (although without
history loss). The rebased code *must* be retested in the new context
anyway. (Linus famously flamed DaveM over this issue on lkml. Sorry,
I don't have the URL.)
To the extent the buildbots are not overloaded, this strategy will
indeed save developer time, as most changes are more or less
independent of each other (that's why automated merging works at all
well), and most of the time something that passes in a branch will
also pass after merging. So it's probably easier, and certainly less
wearing on other developers, if you detect breakage in the branch
rather than waiting for it to happen in the trunk. However, such
early detection is not guaranteed because not all semantic conflicts
are syntactic conflicts. Ie, the merge may succeed but the code
break.
> In fact I am thinking about being able to push a "patch" to the
> buildbots and, if the patch applies cleanly to the branch tip, actually
> apply it, build & test.
This is what Bazaar does with its PQM service ("patch queue manager").
I don't see why that wouldn't be usable with Mercurial, although if
it uses Bazaar internal APIs (a lot of Bazaar-related projects do) it
might be mildly tedious to port).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
