We use a separate cache to avoid problems with
audit = path_auditor(repo.root)
audit("subrepo")
audit("subrepo/file")
whitelisting "subrepo" (which is fine) and then using the same whitelist
with "subrepo/file" (which is not fine).
Since we create a separate path_auditor for every path on the command line,
a "hg add dir/a dir/b dir/c" will still lstat dir 3 times just to audit
the paths.
We weren't reading all the data sent by the server. Depending on
the system, the remote hg (actually, the remote python) could send a
"close failed: [Errno 32] Broken pipe", making some tests fail.
when giving user/pwd in an URL, eg.
hg pull http://user:pwd@host.com:666/hg/something,
hg would still ask for user/pwd in interactive mode (or fail in
non-interactive)
Changeset 31be2f4d36a5 added some code to putcommit to avoid creating a
revision that touches no files, but this can break regular conversions
from some repositories:
- conceptually, since we're converting a repo, we should try to make
the new hg repo as similar as possible to the original repo - we
should create a new changeset, even if the original revision didn't
touch any files (maybe the commit message had some important bit);
- even if a "regular" revision that doesn't touch any file may seem
weird (and maybe even broken), it's completely legitimate for a merge
revision to not touch any file, and, if we just skip it, the
converted repo will end up with wrong history and possibly an extra
head.
As an example, say the crew and main hg repos are sync'ed. Somebody
sends an important patch to the mailing list. Matt quickly applies
and pushes it. But at the same time somebody also applies it to crew
and pushes it. Suppose the commit message ended up being a bit
different (say, there was a typo and somebody didn't fix it) or that
the date ended up being different (because of different patch-applying
scripts): the changeset hashes will be different, but the manifests
will be the same.
Since both changesets were pushed to public repos, it's hard to recall
them. If both are merged, the manifest from the resulting merge
revision will have the exact same contents as its parents - i.e. the
merge revision really doesn't touch any file at all.
To keep the file filtering stuff "working", the generic code was changed
to skip empty revisions if we're filtering the repo, fixing a bug in the
process (we want parents[0] instead of tip).
A new function (extensions.extensions) allows the code that is
interested in those attributes to handle them directly.
This allows some cleanups of extensions.py. Notably, we can
remove the extensions.commandtable hack.
It also makes it easier to add standard extension attributes,
like a "hgwebsetup" function or a "helptable" dict that augments
the data in help.py, etc.
- move command dispatching functions from commands and cmdutil to dispatch
- change findcmd to take a table argument
- remove circular import of commands in cmdutil
- privatize helper functions in dispatch
If convert.hg.clonebranches is set, branches will be created as clones of
their parent revisions. All clones will be subdirectories of the
destination path.
