[jblack: Re: [tools-discuss] Evaluation notes on bzr-0.7]

Robey Pointer robey at lag.net
Wed Mar 1 18:18:01 GMT 2006


On 28 Feb 2006, at 13:13, Aaron Bentley wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Arbash Meinel wrote:
>
>> As far as supporting partial commit after a merge, I doubt we will
>> support that for a while. But it might be possible to realize that  
>> '.'
>> is the entire tree.
>
> I'm pretty sure that '.' wasn't the entire tree, in his example.  He
> said "'.' is the lowest directory common to all merged files".
>
> If we have to, we can compare BASE and OTHER, to determine whether any
> of the files modified by OTHER are not included in the file spec.  But
> that's quite ugly.  I would much rather have commit be fast when no
> filespec is specified.  One model that supports this is BitKeeper,  
> where
> you have to run 'bk edit' to edit each file.

Perforce uses the same model.  I've gotten used to it, but it's not  
very convenient.  Tools have to know about it, or else you can't edit  
files when you open them.  I'm vaguely -0.5 on the concept.  (It irks  
me a little because it feels like they sacrificed my convenience for  
their speed.)

Would it be a fair optimisation to check mtimes on files, and only  
compute SHAs on the ones that have changed?  In other words there  
would be an mtime-cache in addition to the hash-cache.  It would be  
easy for someone to fool it, but it would be much faster at figuring  
out which files have changed.

robey





More information about the bazaar mailing list