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

[Fernando Perez]

Hey Ondrej,

On Wed, Sep 3, 2008 at 3:23 PM, Ondrej Certik <ondrej at certik.cz> wrote:

> I am still trying to find the best workflow, but so far I like this: I
> commit very often and prepare something in my local branch. Then I
> rebase it in a couple of well documented nice commits, put it in some
> public branch (so that people can pull it) and ask for a review. Then,
> if I did a good job and the "fix_crap" commit (there is almost always
> some) is simple, I completely agree with you it should be committed
> after it. But if I did a bad job and the whole branch needs to be
> revised, or just more deep changes are needed, it's imho better to
> rework it. E.g. what happens in your case, if the branch is "not ok to
> go in", but the fix is not just some easy "fix_crap", but some
> fundamental problem -- you just start another branch and use the good
> ideas (patches) from the broken one?

I actually do like the approach you describe, but as far as I've seen,
bzr isn't the friendliest to this type of workflow with frequent
'history rewriting'.  It's my understanding that git is far, far
better suited to this approach.

For now I feel like we've found somewhat of a sweet spot with bzr,
where things aren't perfect but they work OK, we do benefit from the
tools in launchpad and the distributed nature of bzr, and we can
actually spend more time working on ipython than thinking about
version control :)

But your comments regarding history cleanup do linger in the back of
my mind and I've thought about it.  It's just that right now, I want
to focus for a while on using the tools productively (even if they are
imperfect) rather than fidgeting forever with them.

I'm always eager to learn further about this though, especially about
approaches that work better in the context of bzr/launchpad, since I'm
not about to consider another change, at least for a while.

cheers,

f