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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robey Pointer wrote:
>> 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.  

I think that we can make it convenient.  For example, we can have an
inotify daemon that runs 'bzr edit' on every file that we modify.
Fundamentally, it doesn't make sense to me that we have to tell the tool
which files changed, because the OS must already know.

So commit FILENAME should mean "even though I changed other files, I
only want to commit this one."

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

Right, and I understand this.  I was more trying to show that it's not
impossible to design a VCS so that commits on large trees are fast.

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

Unless I misunderstand you, that's how the hashcache works already.  (We
use more stat info than just the mtime, though.)  There may be room to
improve the hashcache, but at a certain size, lstatting the whole tree
will take too long.  It looks like OpenSolaris is around that size already:

lstat64                 4.294  150896       1

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEBgK80F+nu1YWqI0RAkKPAJ9wrdVlGAtLe+Kuf5EW6OZkkgEByQCeKkU5
QSg5qH8aD9uIw6tRVKlAHOI=
=ExN6
-----END PGP SIGNATURE-----