> Caveats: > * the number 50 is hard coded; it really should be a value that > the user can customize.
Before this is viable, it *must* be possible to turn this behaviour off. On large trees, cacherevs are massively wasteful of space; revision libraries are often a more efficient solution. It depends. If you have 50 small patches that fix typos or so, then on a large tree this is wastefull. I think a better heuristic on when to create a new cacherev is not on the _number_ of patches that exist, but how big the collection of all patches since the last cacherev is in bytes. So if you have a tree that is 300MiB, and you fix a couple of documents over 50 revisions, the total size of the patches might be as low as 300KiB, but using the `number of patches' algorithm, you will end up with a new cacherev that takes up 300.3MiB. Not very smart. Using the `total size of previous patches' you won't get a new cacherev here, but you would get one if you have commited say 20MiB worth of patches over a period. This is far smarter, IMHO. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
