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

[Andrew S. Townley]

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.
> 
> cheers

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.

I also do two types of builds:  developer builds and official builds. 
The developer builds are what people have on their own machine, and the
official builds are done on a periodic basis (normally daily in projects
that I have control of), and each one gets tagged with a tag that
includes the build number, e.g. PROJECT_CM_BUILD_12345.  Releases are
tagged based on references to the official build tags.  Drops to test
teams are from the official build machine/location, so you know exactly
what is included.  Also, build notifications include log messages of all
the changes since the last build, so if you're waiting for a fix, you
know if it is in this build or not.

Since bzr doesn't currently support tags, this model doesn't work for
it, but with other systems, while a view of any moment in time of the
source tree might be interesting for one reason or another, any copy
which isn't based on a tag isn't considered anything but a work in
progress.  This applies doubly to the head revision.

I agree with you 100%, but I think you misunderstood why I was saying
what I was saying.

ast (anxiously awaiting tag support... :)

***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************