Workflow with 'never commit broken changes'
Robert Collins
robertc at robertcollins.net
Mon Jun 26 09:29:14 BST 2006
On Thu, 2006-06-22 at 19:04 -0500, John Arbash Meinel wrote:
> 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.
I think its:
For a given graph, choose a path through the graph - i.e. left most
parent from top to bottom. Bisect search the resulting list. When you
have found the node you want, choose a path from it that does not
include any of the nodes you just selected from. bisect search that
list. Repeat until your new list to search is 0 nodes long.
We need to tweak this for three-plus parent nodes, and the easiest way
to do that is to have a pessimistic case where just choose another path
from each parent. That is you need:
* a set of nodes searched
* a queue of nodes to start searching from - the 'tips'
and searching a node is:
* take a path from it that goes as far back as possible but does not
include nodes from the set of searched nodes except optionally for its
final node if no non-searched nodes are reachable.
* add the contents of the path to the already-searched-set
* bisect that path
* if you find a node that is a candidate, add all its parents that are
not in the set already searched to the queue to search amongst, and if
it has no parents then its a search result.
This may return multiple hits for a given search, which is what you
would expect if the same bug is introduced on multiple branches.
> 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.
Agreed.
> 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.
Yup.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060626/e49518a1/attachment.pgp
More information about the bazaar
mailing list