blackbox: tests for the blackbox extension A few tests to cover the blackbox extension. Covers commands, hooks, and incoming changes.

blackbox: adds a 'blackbox' command for viewing recent logs 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.

blackbox: log incoming changes via ui.log() Logs incoming changes to a repo to ui.log(). Includes the number of changes and the hashes of the heads after the new changes. Example log line: 2013/02/09 08:35:19 durham> 1 incoming changes - new heads: cb9a9f314b8b Currently the blackbox logs the unix user that is performing the push/pull. It would be nice to log the http authorized user as well so it works with hgweb, but that's outside the scope of this commit.

blackbox: logs python and extension hooks via ui.log() Logs python and extension hooks to ui.log() for viewing in the blackbox. Example log lines: 2013/02/09 08:35:19 durham> pythonhook-preupdate: hgext.eol.preupdate finished in 0.01 seconds 2013/02/09 08:35:19 durham> exthook-update: echo hooked finished in 0.02 seconds

blackbox: log the commands that are run Uses ui.log to log which commands are run, their exit code, the time taken, and any unhandled exceptions thrown. Example log lines: 2013/02/09 08:35:19 durham> add foo 2013/02/09 08:35:19 durham> add exited 0 after 0.02 seconds Updates the progress tests because they use a mocked time.time() which these changes affect.

blackbox: adds a blackbox extension 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

scmutil: create directories in a race-safe way during update With the new parallel update code, it is possible for multiple workers to try to create a hierarchy of directories at the same time. This is hard to trigger in general, but most likely during initial checkout. To deal with these races, we introduce a new ensuredirs function whose contract is to ensure that a directory hierarchy exists - it will ignore a failure that implies that the desired directory already exists.

Merge

test-atomictempfile: convert to unit test

tests: add a test runner utility that prints nothing when all tests pass This will be used to run tests through run-tests, which will expect no output for a unit test that passes successfully. The motivation for using unit tests instead of the current Python tests is that they don't require an output file for comparison and that they're easier to write because of the available tools from unittest (setup, asserts).

hgweb: consistent author name width Paper & coal use a sligtly shorter name length of 12em in the log view than gitweb's 15em. Names too long for 12em is not entirely unheard of, and hence increasing the length is appropriate; hgweb should remain usable on 1024x768.

dirstate: fix generator/list error when using python 2.7 util.statfiles returns a generator on python 2.7 with c extensions disabled. This caused util.statfiles(...) [0] to break in tests. Since we're only stat'ing one file, I just changed it to call lstat directly.

mq: comply with filtering when injecting fake tags (issue3812) mq was injecting fake tags whenever the revisions were accessible to the filtering level. This issue impacts hgweb since it's common to have "secret" mq patches. As secret changesets are filtered by hgweb, the tags computation could break.

commit: factor out post-commit cleanup into workingctx This pulls some of the logic for the cleanup that needs to happen after a commit has been made otu of localrepo.commit and into workingctx. This is part of a larger refactoring effort that will eventually allow us to perform some types of merges in-memory.

localrepo: use workingctx for validation in commit This changes localrepo.commit to use the workingctx it creates form the munged output of localrepo.status while running some precommit validation. Specifically, it uses functions that were already present on the workingctx. I believe this is a net readabilty improvement, and that this makes these lines consistent with the refactoring in a subsequent patch that pulls some of the validation logic into workingctx so that it can be reused elsewhere.

localrepo: create context used for actual commit earlier localrepo.commit creates a workingctx, calls self.status, does some munging on the changes status returns, does some validation on those changes, and then creates a new workingctx from the changes. This moves the creation of the new workginctx ahead of some validation, with the intention of refactoring some of that validation logic into the workingctx, so that it can be reused elsewhere.

merge with crew-stable

debugobsolete: improve command help The behavior without argument was not documented.

import: don't rollback on failed import --exact (issue3616) The checkexact() helper function was calling repo.rollback() from inside an open transaction. In addition to being insane, this is unnecessary because import will release the transaction on an exception. It turns out that this has been broken since the feature was first introduced, first released in v1.0: changeset: 4263:47ba52121433 user: Brendan Cully <brendan@kublai.com> date: Thu Mar 22 10:44:59 2007 -0700 files: mercurial/commands.py mercurial/patch.py description: Add import --exact. When this option is set, import will apply the patch (which must be generated by export) to the parents specified in the patch, and check that the node produced by the patch matches the node ID in the patch.

Merge

Merge

merge crew and main

merge crew and main

manifestmerge: fix order in which manifests are fetched If the manifest of an earlier revision on the same delta chain is read before that of a later revision, the revlog remembers that we parsed the earlier revision and continues applying deltas from there onwards. If manifests are parsed the other way round, we have to start over from the fulltext. For a fresh clone of mozilla-central, updating from 29dd80c95b7d to its parent aab96936a177 requires approximately 400 fewer zlib.decompress calls, which results in a speedup from 1.10 seconds to 1.05.