[IPython-dev] branch management getting better...

Fernando Perez fperez.net at gmail.com
Sun Aug 17 15:54:43 EDT 2008


On Sun, Aug 17, 2008 at 9:41 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
> 2008/8/17 Fernando Perez <fperez.net at gmail.com>:
>> On Sun, Aug 17, 2008 at 12:57 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
>>> 2008/8/16 Fernando Perez <fperez.net at gmail.com>:
>>>> much more cleanly.  For example, if you go to:
>>>> http://bazaar.launchpad.net/~ipython/ipython/trunk/changes
>>> I can't open this page -- am I doing something stupid?
>> Sorry, as I just changed the team name, the url moved (after I'd
>> written my original email):
>> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/changes
> So, the number to click on is now 1102 (not 1101).  Did this change
> since you wrote the mail?  I'm just wondering whether the graph is
> ever re-labeled.

It shouldn't, but this time it did: in all the storm of doing many
things yesterday, I did a pull instead of a merge, which caused again
the dreaded revision dropping, so the numbers changed.  This is
precisely what I was trying to avoid, so it's a bit embarrassing, I
was just doing too many things and tripped.

If you see now, for example this revision:


got committed (by me) with Gael as author, since I was merging a set
of patches by him.  In a local log you can see the distinction between
committer and author for this one, which is useful: I was committing
work that was 100% Gael's, so this lets us track exactly who did what.
 This message (we've referred to it before) has a nice summary of the
workflow I think we're settling into:


and I now find that I really am starting to agree with the various
reasons he explains there, in particular:

So why the distinction between a mainline and a merge commit. We have a
few use cases for them...

1) "These are the patches reviewed by me". I don't review every single
change someone makes. But I *do* review the merge before I commit it.

2) "Every commit on the mainline passes the test suite". This is a
pretty big one for our bzr.dev process.

3) "Summary of changes". It gives an obvious place to summarize the many
(potentially hundreds or more) commits someone made. You frequently want
to keep all of those hundreds of revisions around, because it gives you
nice, fine grained details about things that have changed. (Useful for
annotate, or any sort of digging that needs to be done).

But having a single summary revision, also lets the people who *don't*
want to wade through 100 revisions to understand "Implemented bound

I'm also starting to use the same approach even when summarizing *my
own* commits: I work on my branch (which is publicly mirrored) and do
lots of small, frequent commits.  Then I merge from it into my local
mirror and push that upstream, with a single summary message.  As we
evolve towards more organized code review, this will be useful.  Once
a set of changes have been reviewed from the developer's branch, they
get merged as a single set into the mainline.  The only direct work
into trunk should be the little tweaks that need to be made at release
time to the version numbering files and such.

Argh, finally getting this...  :)



More information about the IPython-dev mailing list