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

[John Whitley]

On Nov 3, 2005, at 2:29 AM, Andrew S. Townley wrote:
> 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.

It looks to me like two issues are being conflated here: the ability  
to record meaningful
per-file log notes for a commit, versus the idea of an atomic commit  
of all related changes.

Andrew, I'll suggest that what you really need is a commit plugin  
that fires up your editor already primed with the output of "bzr  
status" run on the same scope as the commit.  Then you can easily  
annotate the per-file changes as needed.  By following a simple  
convention in these logs, it would be possible to extract two views  
on changes to the system -- 1) the cross-tree history of atomic  
commits and 2) the per-file "slice" of changes made to that file.

Perforce's commit mechanism is a related example: when submitting a  
changeset, the user is presented with an editor which has several  
areas including:
   * information about the branch
   * the file changes to be submitted
   * an area for comments on the change
Having the file-level changes presented at commit time was a nice  
cheat-sheet for making sure that my changes were thoroughly commented.

FWIW, the commit plugin I mentioned above is really a special case of  
the more general need to prime commit logs with metadata of various  
forms.  E.g. a tag listing bug numbers resolved by this commit, for  
systems that automatically cross-reference with a bug tracking  
system, etc.

-- John