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

[Ondrej Certik]

On Sun, Aug 17, 2008 at 9:54 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hey,
>
> 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:
>
> http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/revision/1103
>
> 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:
>
> https://lists.ubuntu.com/archives/bazaar/2007q1/023972.html
>
> 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
> branches".
> """
>
> 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.

I have couple more questions to the workflow:

So you publish let's say 30 little commits in your branch. Stefan
reviews it, let's say he says the commits 15, 20 and 21 are crap and
you should rework it. :) So will you add commits 31, 32 and 33 fixing
the crap, or will you actually edit the commits 15, 20, 21 directly?
Does bzr allow you to easily delete the public branch and repost your
reworked 30 little commits?

Because you said you merge those 30 little commits into one or a few
commits, so people who pulled your branch will have mess in their
repos, right?

I like the direct editing workflow, i.e. I also like to commit 30
little commits and then merge it in a few well polished patches, send
them for a review (e.g. push them into some branch), then fix things
couple times depending on the review and finally the commits go in the
main trunk. And I realized that mercurial is getting in my way in this
workflow, and we switched to git with Kirill (another sympy developer)
and it allows me to work in the way I described very easily and also
to push the reworked patches to the same public branch (removing the
old stuff).

Ondrej