If enabled, log rotation prevents the amount of space used by the
blackbox log from growing without bound. This becomes important in
cases where there are a lot of busy repositories managed by humans
and automation on many machines.
In large deployments, we cannot reasonably track all the repos where
blackbox logs need to be managed, so it is safer to have blackbox
manage its own logs than to move responsibility to an external tool
such as logrotate.
This change adds two configuration keys:
* blackbox.maxsize is the maximum allowable size of the current log
* blackbox.maxfiles is the number of log files to maintain
Previously, we opened the log file when creating a repo object. This
was inefficient (not all repo creation is going to result in a need to
log something), but more importantly it broke subrepo updates when used
on NFS.
* perform an update in the master repo that triggers a subrepo clone
* empty subrepo already exists, and has an open, empty blackbox.log file
due to it being opened eagerly/prematurely
* hg decides to blow away the skeletal subrepo (see use of shutil.rmtree
in subrepo._get)
* we crash, due to NFS treating a delete of an open file as really a
rename to a hidden ".nfs" file
Now that we open the blackbox log file on demand, no file exists at the
time the empty subrepo is deleted, so the above problem does not occur.
Adds a 'hg blackbox' command for viewing the latest entries in the blackbox log.
By default it shows the last 10 entries, but -l allows the user to specify.
Adds a blackbox extension that listens to ui.log() and writes the messages to
.hg/blackbox.log. Future commits will use ui.log() to log commands, unhandled
exceptions, incoming changes, and hooks. The extension defaults to logging
everything, but can be configured via blackbox.track to only log certain events.
Log lines are of the format: "date time user> message"
Example log line:
2013/02/09 08:35:19 durham> 1 incoming changes - new heads: d84ced58aaa
