Update: Re: bzr 0.6 commit problem: parent_id {blah} not in inventory

[Michael Ellerman]

On Thu, 3 Nov 2005 21:29, Andrew S. Townley wrote:
> On Thu, 2005-11-03 at 10:07, Michael Ellerman wrote:
> > On Thu, 3 Nov 2005 20:24, Andrew S. Townley wrote:
> >
> > That's one school of thought. The other is that you should never check in
> > something that doesn't build and or work. "Don't break the build!"
> >
> > If you think about it, partial commits allow you to create revisions in
> > history that never actually existed in your working tree, which means you
> > never built or tested them.
> >
> > So I agree that it's important not to have a 2K diff of 100 files that
> > says "Updated stuff", I also think it's dangerous to check in revisions
> > that you haven't built, no matter how careful you are you'll get it wrong
> > one day.
>
> Actually, the "don't break the build" was exactly my point and why I got
> into the situation in the first place.  What I was checking in was
> *finished* work that I had not only built and unit tested, but also had
> done a fair amount of functional/experimental testing of it in context
> as well.
>
> While I admit that me checking in individual files with meaningful log
> messages takes minutes vs. the seconds that doing a global commit does,
> I'll happily take that trade-off to have meaningful log messages.  I
> want both things:  meaningful log messages and a tree that builds :)
> However, if the tree doesn't build for 5-10 minutes and then it doesn't,
> the chances of it disrupting people doing work is pretty low except in
> the chance that they did an update while this was happening.

Right, but by checking in individual pieces of the finished work, you create 
revisions in the tree that don't build/work. If in the future you need to 
binary search through your history for a regression that can be a real pain.

Apparently BitKeeper supported per-file commit messages, so you could have a 
different message for each file, but still one commit. That strikes me as 
overkill for most cases though.

What would be nice, and I think is in the pipeline, is being able to assign 
abitrary meta-data to a commit. So you can have your test-suite run on each 
commit, and mark the commit as either WORKING or BROKEN. Then when someone's 
searching for a regression they can only try WORKING revisions.

For the record, I'm not suggesting that partial commits shouldn't be allowed, 
I just think they shouldn't be the default. You can emulate the 
commit-in-this-sub-tree behaviour with "bzr commit ." which is pretty easy. 
Although as John (I think) said, there might be some bugs lurking in there.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051104/7e80ac6e/attachment.pgp