[IPython-dev] Bzr merge idiosyncracies...

Fernando Perez fperez.net at gmail.com
Wed Jun 4 03:02:56 EDT 2008

On Tue, Jun 3, 2008 at 11:55 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Wed, Jun 4, 2008 at 5:01 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>> I can't believe that this is actually something that bazaar considers
>> a 'feature' and they promote as a valid design point.  The fact that
>> you've merged someone else's work into your branch because you happen
>> to be a maintainer, for example, doesn't make their work in any way
>> 'second class'.  I agree 100% percent with Linus here (post linked to
>> in the vcscompare post):
> This is something that works very well in practice, provided that the
> branch work is of reasonable size - one feature, bugfix, etc. The idea
> is that the log message is detailed enough to describe what was
> merged. It should not be "merged stuff".
> This liberates the commit policy in the branch, you can experiment and
> play around a bit more when the end result will appear as single
> well-contained commit.
> In my last project the policy was "single commit per bugfix", using an
> official commit template. It worked just fine, and you could easily
> find what bugfix caused a problem, who did it, etc. You are not
> interested it 10+ micro-commits that the original fixer did.
> We should pick up a policy where we add the branch owners name as the
> first thing in the log message, for people who don't have trunk
> access.
> As far as linux goes - the development hierarchy is multilayered,
> which is not the case with us. There are no people who consolidate
> small branches to big branches that are merged to trunk, but rather
> the small branches are integrated directly to trunk.

It would be really good if you put some of these 'bzr good workflow
practices' in the wiki dev guidelines page.  Feel free to make it all
rst right away: that way when Brian integrates the docs, he can just
grab it from there.  Moin renders rest just fine, with a directive:


You have a *much* better sense for how to work with, rather than
against, bzr.  We'd all benefit from that insight before we mangle the
ipython tree into a crazy mess...

The single commit per bugfix is probably also a good policy because
I'm starting to get the feel that there's ONE file that is going to
give us grief: the linear ChangeLog.  That's the one file where
conflicts are likely to appear if we all edit it, so we might be
better off probably NOT using it anymore, and relying on the commit
logs instead.  But for that to be viable, the commit logs must be a
suitable replacement of the current Changelog, so they need to have an
entry per actual change, and must be more than one-liners.  Otherwise
there will be no easily human-readable log later anywhere.  Does that
sound right?



More information about the IPython-dev mailing list