Workflow with 'never commit broken changes'

[John Arbash Meinel]

Aaron's recent branch/merge/pull question reminded me of a subtle thing
that the hg guys mentioned. One of the things Linus has told people is
"never commit broken code, because then you can't use bisect search to
find when a bug appears".

Now, my understanding is that the hg guys wrote a bisect algorithm which
is merge aware. They didn't go into the details, but it sounded like
they used the merge graph to help eliminate revisions to check.
In my head it works something like: go to a merge point, build and run
the test. If it fails, check each parent, if one fails and the other
doesn't you have isolated the branch that the change occurred on.

I'm guessing it is a little bit more complex than that, but the basic
idea is that you can bisect your way through history, but since you have
a branching topology, you can use the knowledge of the DAG to jump over
large portions.

It sounds like an interesting tool. I don't know if we've ever had a
need to find 'what revision introduced this bug'. It may just be that
our project is small enough that you don't have bugs cropping up in a
manner that the code which is causing it is unclear. (Plus we have a
test suite, which helps us isolate that it is very unlikely for known
bugs to sneak in).

What I was thinking about, though, is that I commit broken code fairly
often. I try not to, but it is fairly common that I'm working on feature
A, and to fix it, I need to fix feature B, which I want to commit
separately, but in the process I don't worry too much that the entire
test suite is passing.
Or I've been working on my laptop, an I want to move over to my desktop.
Robert mentioned this is abusing bzr as a substitute for rsync/unison.
He has a point, but I also know that rsync may through away uncommitted
changes on my desktop (or even committed changes that I don't have).

We never commit things to the mainline which is broken (which I do
support). But I have to wonder what broken commits on side branches
might do for something like 'bisect'.

But I realized that if your bisect search was really merge aware, it
shouldn't actually hurt if some of the commits in a merge branch are
broken. Because the tip of your branch should be clean, and certainly
where it merges into mainline should be clean, it only matters if you
are the one who introduces that particular bug.
But it would seem the 'bisect' search should be able to localize what
branch brought the bug in, before it tried to find the exact revision,
which would give you 90% of what you want.

I realize I'm trying to justify committing broken code (only in a
dev/personal branch). But I think there are circumstances that "NEVER
COMMIT BROKEN CODE", would be very restrictive. eg. I'm in the processes
of changing X to Y, and I've fixed 80% of the cases, but I need to go to
sleep. Do I have to wait until I hit 100% to add a new revision?

Anyway, it would seem to me that the tools should be built to cope with
human imperfection, rather than waiting until they are perfect for them
to continue.

I'm not a kernel hacker, so maybe I'm missing some true enlightenment.
Creating a dev process around your tools is required to some extent
(human beings are generally more flexible than any tool). But
ultimately, you should try to build your tools around the process you
want to use.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060622/0003f3f3/attachment.pgp