Workflow with 'never commit broken changes'

[Jan Hudec]

On Mon, Jun 26, 2006 at 10:29:51 -0500, John Arbash Meinel wrote:
> Michael Ellerman wrote:
> > On 6/23/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
> >> 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).
> > 
> > For that case I'd commit, push, then uncommit on both sides. It's a
> > bit of a pain, but better IMHO. I notice there's a new bzrtools
> > command called "shove" which caters to this use case even better.
> > 
> >> 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 why the distinction? If things only work on the mainline, that
> > might leave you trawling for a bug introduced in a 10,000 line-diff
> > branch merge.

Well, I think there is a certain level above which there should never be
broken code checked in and below which sometimes might. Eg. one might
commit broken code to a feature-branch occasionally, but not to an
integration branch. So IMHO bisect could print at which revision it is
every time the branch nick changes. For example it would yield:

pqm at bar.net-SOMENUMBER (mainline) Merge the flobaz stuff.
foo at bar.net-OTHERNUMBER (foo-integration) Prepare quux for flobaz.
foo at bar.net-WHATEVER (quux) Add qyzzy to quux.

And than the author would know, whether the quux branch contains broken
code or not. If it does not, than the last line is the commit that
really broke it. But if it does contain broken code, than the last line
is likely nonsense, but the line above that is still useful hint about
where the bug was introduced, since the code checked in foo-integration
is supposed to work.

For this I think rather than considering history along the first parent,
it would have to preferentially consider history along the same branch
nick.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060627/14ace472/attachment.pgp