[PATCH] faster initial commit due to buffered logging

Ian Clatworthy ian.clatworthy at internode.on.net
Tue May 29 01:08:50 BST 2007


Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian Clatworthy wrote:
>   
>> The attached patch builds on the previous submitted one and includes
>> better comments in response to feedback from Andrew Bennetts.
>>     
>
> It would be nice to also see the overall changes, since this patch
> appears to supersede your previous one*.  I'd like to suggest the
> pattern I used for my "[MERGE] more common-ancestor performance
> improvements": include a merge request or bundle with all the relevant
> revisions, and a patch showing the new changes.  That way, people who
> don't have your previous bundle can still merge.
>
>   
That should be no problem. Here's what I did:

1. Created a branch
2. Made cleanups, committed and submitted a bundle
3. Made more changes, committed and submitted a patch excluding the 
first commit

Getting a bundle with all the changes is simple - I had to work harder 
to avoid that and maybe I should not have bothered. My expectation 
though when I started was that the cleanups ought to go through review 
quickly while the follow-up changes would require more time.

Note: After this logging change, other stuff on my list includes 
reducing multiple file reads: once for SHA and once for content currently.

I gather that BB will handle everything all OK if both a bundle and a 
patch are attached to an email?
> It seems like we should make it an error to invoke anything after
> invoking CommitReporter.completed.  Do you agree?  (We'd have to start
> by issuing DeprecationWarnings, I think.)
>
>   
Either that or make _flush() public and call it explicitly from 
cleanUp(). There is definitely a hole in the design currently where the 
'added' messages will never appear unless completed() (or another 
'interesting' message) is called.
> Also, it seems like it might make sense to use (and slightly extend)
> delta._ChangeReporter for this, to unify the output formats.
>
>   
I'll look at this today.
> *In fact, I'm not sure why BundleBuggy hasn't marked your previous one
> "Superseded".
>
>   
I included an explanation of the steps I took (above) in case that helps 
answer this.

Ian C.



More information about the bazaar mailing list