While I was here, I removed the try..except around importing cStringIO
because cStringIO should always be importable on modern Python versions.
We already do an unconditional import in other files.
Without this, running gendoc.py during an install without C modules
available (via `make local`) will result in an import failure because
the default module load policy insists on C modules.
We also remove the sys.path adjustment because it is no longer needed
since our magic importer handles things.
This has a small, but measurable, effect on performance if a pattern
file is very large. In an artificial test with 200,000 lines of
pattern data, using re2 reduced read time by 200 milliseconds.
Before, hg help -c was the same as hg help, now it only shows commands.
Before, hg help -e was the same as hg help, now it only shows extensions.
Before, hg help -k crashed, now it shows all topics.
Since 3be994f0f015, #fragment was missing in "hg paths" output because
path.loc was changed to a parsed URL. "hg paths" should use path.rawloc to
show complete URLs.
is None (issue4983)
Some hooks, such as post-init and post-clone, do not get a repo parameter in
their environment. If there is no repo, there is no repo.currenttransaction();
attempting to retrieve it anyway was causing crashes. Now currenttransaction is
only retrieved and written if the repo is not None.
When committing interactively without changes, the user would get a ValueError
exception. This patch adds a dictionary to the return value of filterpatch
when there are no files to change.
The 'peer.known' call (handled at the repository level) was applying its own
manual filtering (looking at phases) instead of relying on the repoview
mechanism. This led to the discovery finding more "common" node that
'getbundle' was willing to recognised. From there, bad things happen, issue4982
is a symptom of it. While situations like described in issue4982 can still
happen because of race conditions, fixing 'peer.known' is important for
consistency in all cases.
We update the code to use 'repoview' filtering. This lead to small changes in
the tests for exchanging obsolescence marker because the discovery yields
different results.
The test affected in 'test-obsolete-changeset-exchange.t' is a test for
issue4982 getting back to its expected state.
A fix to issue4982 (not fixed in this patch) will reinforce the filtering
during discovery. This will makes two of our test repositories appear
unrelated (because all common content is properly hidden). To avoid this, we
introduce an extra base changeset that will not get obsoleted. This affects
various test output so we put this addition in its own changeset.
We currently allow updating and merging (with --force) when there are
unresolved merge conflicts, as long as there is only one parent of the
working copy. Even worse, when updating to another revision
(linearly), if one of the unresolved files (including any conflict
markers in the working copy) can now be merged cleanly with the target
revision, the file becomes marked as resolved.
While we could potentially allow updates that affect only files that
are not in the set of unresolved files, that's considerably more work,
and we don't have a use case for it anyway. Instead, let's keep it
simple and refuse any merge or update (without -C) when there are
unresolved conflicts.
Note that test-merge-local.t explicitly checks for conflict markers
that get carried over on update. It's unclear if that was intentional
or not, but it seems bad enough that we should forbid it. The simplest
way of fixing the test case is to leave the conflict markers in place
and just mark the files resolved, so let's just do that for now.
While I was here, I removed condition code for failure to import json.
This code was necessary to support Python < 2.6, which didn't include
the json module.
My version of docker (1.8.3) have a different formating for 'docker version'
that broke the build script. We make the version matching more generic in to
work with both version.
