"Joel Crisp" <[EMAIL PROTECTED]> writes: [...]
> Would it make sense to provide a monitor for files under monotone > control which would queue a changed file for a low prioirty background > task to fingerprint it into a cache of current fingerprints? Then come > a commit etc operation monotone could first check the cache of > fingerprints and not have to recalculate them during the operation. My hunch is that it's not worthwhile. Presuming inodeprints, you'd be saving a stat() of every file followed by a hash of apparently changed files (well, you'd be moving the hashes earlier). I'd guess those aren't that significant, most of the time. It shouldn't be hard to measure, so you could get some indication of the available savings fairly easily, I should think. _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
