Without this, the last logged entry didn't have access to
the repository, and thus couldn't report its version
(and especially that an add or similar dirtied it).
A side-effect is that one repo leaks until process exit...
Without this, while you could see the list of commands run,
it wasn't possible to identify what they were doing, because commads
could rely on revsets (including remote input which varies over time).
Without this, when there are multiple ui views, each blackbox
will have its own file handle, and the logging will be in
a really bad order.
Also, because of the way blackbox works, it never closes its
file handles, which means the last output before exit is
often lost.
This adds the process id to the line header for the blackbox output. This is
useful for distinguishing processes when using the blackbox on a server and many
processes are writing to the blackbox at once.
We now have multiple tags cache files. Record exactly which file is
being written. This should help aid debugging into performance issues
with any single filter.
Since we changed the format of the tags cache, we should bump the
filename. Before this patch, "tags" was being used for unfiltered
repositories. Change the naming scheme to be consistent and ensure
that a new cache file is used.
While I was here, I updated the docs to describe the existence of
multiple caches. I also added explicit test coverage for the creation of
the unfiltered tags cache.
.hgtags fnodes are now written to a shared cache file. They don't need
to exist in the per-filter tags cache files. Stop writing them.
The format of the tags cache file has changed in a backwards
incompatible way. This should be acceptable, as we just established
per-filter tags cache files and no client should have per-filter tags
cache files that will need to be read. So no backwards compatbility
concern is present.
The new format has a single header line followed by resolved tags
entries.
The header line is similar to the old first line with a major
difference: we now compute and store a hash of the filtered revisions.
Before, if the set of filtered revs changed, we may return incorrect
results. We now detect that.
A test for verifying filtered rev change is handled properly has been
added.
Currently whichever filter level asks for tags last will write the data on disk.
This create massive issues when tags are read for "visible" and "unfiltered"
on large and multi headed repository (like Mozilla central). See issue4550 for
details
Each filter level recomputes its own cache without direct collaboration but they
all share the same 'hgtagsfnodes' cache. And that is where most of the time is
spent.
