revbranchcache: populate cache incrementally Previously the cache would populate completely the first time it was accessed. This could take over a minute on larger repos. This patch changes it to update incrementally. Only values that are read will be written, and it will only rewrite as much of the file as strictly necessary. This adds a magic value of '\0\0\0\0' to represent an empty cache entry. The probability of this matching an actual commit hash prefix is tiny, so it's ok if that's always considered a cache miss. This is also BC safe since any existing entries with '\0\0\0\0' will just be considered misses. Perf numbers: Mozilla-central: hg --time log -r 'branch(mobile)' -T. Cold Cache: 14.7s -> 15.1s (3% worse) Warm Cache: 1.6s -> 2.1s (30% worse) Mozilla-cental: hg perfbranchmap 2s -> 2.4s (20% worse) hg: hg log -r 'branch(stable) & branch(default)' Cold Cache: 3.1s -> 1.9s (40% better - because the old code missed the cache on both branch() revset iterations, so it did twice the work) Warm Cache: 0.2 -> 0.26 (30% worse) internal huge repo: hg --time log -r 'tip & branch(default)' Cold Cache: 65.4s -> 0.2s (327x better) While this change introduces minor regressions when iterating over every commit in a branch, it massively improves the cold cache time for operations which touch a single commit. I feel the better O() is worth it in this case.

revbranchcache: move entry writing to a separate function This moves the actual writing of entries to the cache to a separate function. This will allow us to use it in multiple places. Ex: in one place we will write dummy entries, and in another place we will write real data.

revbranchcache: store repo on the object Previously we would instantiate the revbranchcache with a repo object, use it briefly, then require it be passed in every time we wanted to fetch any information. This seems unnecessary since it's obviously specific to that repo (since it was constructed with it). This patch stores the repo on the revbranchcache object, and removes the repo parameter from the various functions on that class. This has the other nice benefit of removing the double-revbranchcache-read that existed before (it was read once for the branch revset, and once for the repo.revbranchcache).

revbranchcache: move out of branchmap onto localrepo Previously the revbranchcache was a field inside the branchmap. This is bad for a couple reasons: 1) There can be multiple branchmaps per repo (one for each filter level). There can only be one revbranchcache per repo. In fact, a revbranchcache could only exist on a branchmap that was for the unfiltered view, so you could have branchmaps exist for which you couldn't have a revbranchcache. It was funky. 2) The write lifecycle for the revbranchcache is going to be different from the branchmap (branchmap is greedily written early on, revbranchcache should be lazily computed and written). This patch moves the revbranchcache to live as a field on the localrepo (alongside self._branchmap). This will allow us to handle it's lifecycle differently, which will let us move it to be lazily computed in future patches.

revbranchcache: add test for when the cache is not writable The revbranchecache code already handled the case when the cache file wasn't writable, but let's add a test as well so future changes don't regress this.

patch.trydiff: add a docstring It took me a bit to figure out what this function actually does.