Yuya Nishihara <yuya@tcha.org> [Tue, 24 Nov 2015 23:03:54 +0900] rev 27352
commandserver: cut import cycle by itself
We generally make modules importable from the front-end layer, dispatch ->
commands -> x. So the import cycle to dispatch should be resolved by the
commandserver module.
Yuya Nishihara <yuya@tcha.org> [Tue, 24 Nov 2015 22:58:40 +0900] rev 27351
commandserver: use absolute_import
timeless <timeless@mozdev.org> [Mon, 14 Dec 2015 22:21:30 +0000] rev 27350
tests: histedit-helpers fixbundle should not complain about no input
timeless <timeless@mozdev.org> [Mon, 14 Dec 2015 22:34:30 +0000] rev 27349
tests: relax histedit issue4251 and issue3893 backups
I'm globbing these because some are globbed, and this pair
gets in the way of the main parts of the series.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 13 Dec 2015 09:40:53 -0800] rev 27348
setup.py: use bytes literals
The b() helper was needed because Python < 2.6 didn't support bytes
literals (b''). Now that we don't support Python < 2.6, we no longer
need this helper.
Mathias De Maré <mathias.demare@gmail.com> [Tue, 15 Dec 2015 07:17:15 +0100] rev 27347
clonebundles: fix typo
Augie Fackler <augie@google.com> [Mon, 14 Dec 2015 20:47:22 -0500] rev 27346
merge: rework manifestmerge to use a matcher
This opens the door to working slightly more closely with the manifest
type and letting it optimize out some of the diff comparisons for us,
and also makes life significantly easier for narrowhg.
Augie Fackler <augie@google.com> [Mon, 14 Dec 2015 20:37:41 -0500] rev 27345
merge: restate calculateupdates in terms of a matcher
Once we get a matcher down into manifestmerge, we can make narrowhg
work more easily and potentially let manifest.match().diff() do less
work in manifestmerge.
Augie Fackler <augie@google.com> [Mon, 14 Dec 2015 18:54:03 -0500] rev 27344
merge: have merge.update use a matcher instead of partial fn
This is relatively rarely used functionality, but migrating this to a
matcher will make future work on narrow clones more feasible.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Dec 2015 09:57:05 -0800] rev 27343
treemanifest: don't iterate entire matching submanifests on match()
Before 2773540c3650 (match: remove unnecessary optimization where
visitdir() returns 'all', 2015-05-06), match.visitdir() used to return
the special value 'all' to indicate that it was known that all
subdirectories would also be included in the match. The purpose for
that value was to avoid calling the matcher on all the paths. It
turned out that calling the matcher was not a problem, so the special
return value was removed and the code was simplified. However, if we
use the same special value for not just avoiding calling the matcher
on each file, but to avoid iterating over each file, it's a much
bigger win. On commands like
hg st --rev .^ --rev . dom/
we run the matcher (dom/) on the two manifests, then diff the narrowed
manifest. If the size of the match is much larger than the size of the
diff, this is wasteful. In the above case, we would end up iterating
over the 15k-or-so files in dom/ for each of the manifests, only to
later discover that they are mostly the same. This means that runningt
the command above is usually slower than getting the status for the
entire repo, because that code avoids calling treemanifest.match() and
only calls treemanifest.diff(), which loads only what's needed for the
diff.
Let's fix this by reintroducing the 'all' value in match.visitdir()
and making treemanifest.match() return a lazy copy of the manifest
from dom/ and down (in the above case). This speeds up the above
command on the Firefox repo from 0.357s to 0.137s (best of 5). The
wider the match, the bigger the speedup.
Bryan O'Sullivan <bos@serpentine.com> [Sat, 12 Dec 2015 20:59:37 -0800] rev 27342
pathencode: remove an unused assignment
Bryan O'Sullivan <bos@serpentine.com> [Sat, 12 Dec 2015 20:57:01 -0800] rev 27341
parsers: narrow scope of a variable to be less confusing
Bryan O'Sullivan <bos@serpentine.com> [Sat, 12 Dec 2015 20:10:33 -0800] rev 27340
manifest: fix formatting
One poor unfortunate line was hanging way off the right hand side
of the universe. Rescued it.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:39:29 -0500] rev 27339
parsers: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:46:32 -0500] rev 27338
osutil: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:37:56 -0500] rev 27337
mpatch: use absolute_import
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:35:41 -0500] rev 27336
diffhelpers: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:34:55 -0500] rev 27335
bdiff: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:33:47 -0500] rev 27334
base85: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:32:25 -0500] rev 27333
destutil: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:30:47 -0500] rev 27332
obsolete: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:27:31 -0500] rev 27331
contrib: ignore empty files in check-py3-compat.py
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Dec 2015 13:23:29 -0500] rev 27330
doc: make gendoc.py module import policy aware
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.
Matt Mackall <mpm@selenic.com> [Fri, 11 Dec 2015 17:45:19 -0600] rev 27329
merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 11 Dec 2015 12:21:26 +0000] rev 27328
check-commit: add a test for the patch checking script in contrib
This introduces a test for the change introduced in 8f5735b4aca5.
Bryan O'Sullivan <bos@serpentine.com> [Thu, 10 Dec 2015 21:33:55 -0800] rev 27327
match: use re2 in readpatternfile if possible
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.
Bryan O'Sullivan <bos@serpentine.com> [Thu, 10 Dec 2015 21:32:19 -0800] rev 27326
test-hgignore.t: add tests for comments
Although support for comments in hgignore files has existed for a
while, it was previously untested.
timeless <timeless@mozdev.org> [Wed, 09 Dec 2015 05:56:54 +0000] rev 27325
help: fix help -c/help -e/help -k
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.
timeless <timeless@mozdev.org> [Wed, 09 Dec 2015 19:09:35 +0000] rev 27324
help: call filtercmd from topicmatch
update test coverage to explicitly define when help -c should
list debug/deprecated items.
timeless <timeless@mozdev.org> [Wed, 09 Dec 2015 19:09:06 +0000] rev 27323
help: refactor filtercmd
timeless <timeless@mozdev.org> [Mon, 30 Nov 2015 19:28:26 +0000] rev 27322
transplant: use Oxford comma
Laurent Charignon <lcharignon@fb.com> [Wed, 09 Dec 2015 17:01:27 -0800] rev 27321
crecord: add dictionary to default return value of filterpatch
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.
Yuya Nishihara <yuya@tcha.org> [Mon, 07 Dec 2015 21:42:50 +0900] rev 27320
paths: include #fragment again
Since 5f2a4fc3c4fa, #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.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Dec 2015 16:12:15 -0800] rev 27319
discovery: properly filter changeset in 'peer.known' (issue4982)
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.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 09 Dec 2015 14:22:57 -0800] rev 27318
test: add an extra base changeset in test-obsolete.t
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.
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 20:21:08 +0000] rev 27317
parents: provide equivalent revsets in help
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 Dec 2015 20:43:24 -0800] rev 27316
merge: refuse update/merge if there are unresolved conflicts (BC)
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.
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 07:05:37 +0000] rev 27315
tests: drop require slow in test-contrib-perf
* skip presleep
* use a stub mode which does not output and generally loops only once
* only use one node for perfparents
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 08:37:12 +0000] rev 27314
convert/svn: quiet check-config
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 08:21:46 +0000] rev 27313
check-config: handle multiline config
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 08:36:00 +0000] rev 27312
check-config: escape period in regexp for inline comments
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 09:09:01 +0000] rev 27311
check-config: allow numbers in configs
p4...
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 09:22:53 +0000] rev 27310
check-config: recognize convert style documentation
timeless <timeless@mozdev.org> [Tue, 08 Dec 2015 04:56:26 +0000] rev 27309
tests: use a single repo for test-contrib-perf
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 19:05:56 +0000] rev 27308
perf: perfrevlog optimize for perf.stub
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 19:05:32 +0000] rev 27307
perf: add getlen
getlen will return 1 if perf.stub
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 18:08:50 +0000] rev 27306
perf: add optional rev for perflog and perftemplating
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 18:18:07 +0000] rev 27305
perf: perfparents honor config perf.parentscount
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 17:41:30 +0000] rev 27304
perf: offer perf.stub to only run one loop
timeless <timeless@mozdev.org> [Fri, 04 Dec 2015 17:41:02 +0000] rev 27303
perf: improve grammar of gettimer comment
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:20:08 -0800] rev 27302
tests: use absolute_import in tinyproxy
Thus begins a series of adding absolute_import to a bunch of files for
Python 3 compatibility.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:02:39 -0800] rev 27301
tests: use absolulte_import in test-wireproto.py
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:05:19 -0800] rev 27300
tests: use absolute_import in test-walkrepo
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:27:53 -0800] rev 27299
tests: use absolute_import in hgweberror.py
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:27:18 -0800] rev 27298
tests: use absolute_import in hghave.py
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:26:12 -0800] rev 27297
tests: use absolute_import for heredoctest.py
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:25:41 -0800] rev 27296
tests: use absolute_import in /get-with-headers.py
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:23:37 -0800] rev 27295
tests: use absolute_import in generate-working-copy-states.py
Anton Shestakov <av6@dwimlabs.net> [Fri, 13 Nov 2015 14:35:36 +0800] rev 27294
hgweb: move entry-preparing code from webcommands to webutils.commonentry()
The new function is used to fill basic information about a ctx, such as
revision number and hash, author, commit message, etc. Before, every webcommand
used to get this basic information on its own using some boilerplate code, and
some things in some places just weren't available.
timeless <timeless@mozdev.org> [Mon, 30 Nov 2015 19:30:16 +0000] rev 27293
grammar: favor zero, one, two over ... or no
timeless <timeless@mozdev.org> [Mon, 30 Nov 2015 19:29:46 +0000] rev 27292
commands: use Oxford comma (help clone)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 09 Dec 2015 08:28:53 +0900] rev 27291
commit: make commit acquire store lock before processing for consistency
If acquisition of wlock waits for another "hg commit" process to
release it, dirstate will refer newly committed revision after
acquisition of wlock.
At that time, '00changelog.i' on the filesystem contains this new
revision, but in-memory 'repo.changelog' doesn't, if it is cached
without store lock (slock) before updating by another "hg commit".
This makes validating parents at re-loading 'repo.dirstate' from
'.hg/dirstate' replace such new revision with 'nullid'. Then,
'localrepository.commit()' creates "orphan" revision (see issue4368
for detail).
a01d3d32b53a makes 'commands.commit()' acquire both wlock and slock
before processing to avoid this issue at "hg commit".
But similar issue can occur even after a01d3d32b53a, if 3rd party
extension does:
- refer 'repo.changelog' outside wlock scope, and
- invoke 'repo.commit()' directly (instead of 'commands.commit()')
This patch makes 'commit()' acquire slock before processing, to refer
recent changelog at validating parents of 'repo.dirstate'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 09 Dec 2015 08:28:53 +0900] rev 27290
censor: make censor acquire locks before processing
Before this patch, "hg censor" executes below:
- without acquisition of wlock, examine whether the working
directory refers the revision of the file to be censored or not
- without acquisition of store lock (slock), replace existing
filelog of file to be censored with censored one,
Replacement consists of steps below, and it is assumed that the
destination filelog at (1) isn't changed before renaming at (3).
1. read existing filelog in
2. write filelog entries (both censored and not) into temporary file
3. rename from temporary file to existing filelog to be censored
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
This patch makes "hg censor" acquire wlock and slock before
processing.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 09 Dec 2015 08:28:53 +0900] rev 27289
transplant: widen wlock scope of transplant for consitency while processing
Before this patch, "hg transplant" executes below before acquisition
of wlock.
- cmdutil.checkunfinished()
- repo.status() for dirty check
- repo.dirstate.parents()
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
This patch makes "hg transplant" acquire wlock before processing
instead of acquiring wlock in each of 'transplanter.apply()' and
'transplanter.recover()'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 09 Dec 2015 08:28:53 +0900] rev 27288
shelve: remove redundant acquisition of wlock for sub commands of unshelve
Previous patch ensures that wlock is acquired before processing for
"hg unshelve". It makes acquisition of wlock in each functions below
redundant.
- unshelveabort() for "unshelve --abort"
- unshelvecontinue() for "unshelve --continue"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 09 Dec 2015 08:28:53 +0900] rev 27287
shelve: widen wlock scope of unshelve for consistency while processing
Before this patch, "hg unshelve" of shelve extension executes below
before acquisition of wlock:
- cmdutil.checkunfinished()
- examine existence of (specified) shelve file
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
This patch widens wlock scope of "hg unshelve" of shelve extension for
consistency while processing.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 17:07:50 -0800] rev 27286
perf: add perflrucachedict command
It measures time to construct, perform gets, sets, or mixed mode
operations on a cache of configurable size with variable numbers of
operations.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:22:09 -0800] rev 27285
tests/filterpyflakes: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:14:39 -0800] rev 27284
tests/fakepatchtime.py: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:13:36 -0800] rev 27283
tests/fakedirstatewritetime.py: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:12:07 -0800] rev 27282
tests/dumbhttp: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:10:10 -0800] rev 27281
tests/autodiff.py: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:07:13 -0800] rev 27280
tests/test-ancestor: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:39:12 -0800] rev 27279
tests: add test for Python 3 compatibility
Python 3 is inevitable. There have been incremental movements towards
converting the code base to be Python 3 compatible. Unfortunately, we
don't have any tests that look for Python 3 compatibility. This patch
changes that.
We introduce a check-py3-compat.py script whose role is to verify
Python 3 compatibility of the files passed in. We add a test that
calls this script with all .py files from the source checkout.
The script currently only verifies that absolute_import and
print_function are used. These are the low hanging fruits for Python
compatbility. Over time, we can include more checks, including
verifying we're able to load each Python file with Python 3. You
have to start somewhere.
Accepting this patch means that all new .py files must have
absolute_import and print_function (if "print" is used) to avoid
a new warning about Python 3 incompatibility. We've already
converted several files to use absolute_import and print_function
is in the same boat, so I don't think this is such a radical
proposition.
Matt Mackall <mpm@selenic.com> [Mon, 07 Dec 2015 18:06:13 -0600] rev 27278
merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:14:49 -0800] rev 27277
localrepo: reinstate localrepo.parents with a deprecation warning
The function was dropped in 3fe8cb40c9c5. This API drop brokes three of my
extensions including some critical to my workflow like tortoisehg. Lets mark
this API for death and give people time to fix their code.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:34:07 -0800] rev 27276
bookmark: deprecate 'bmstore.write' method
This function does not collaborate with the transaction and must disappear. As
we have likely a lot of third party users, we make it deprecated to let them some
time to upgrade their code.
Thanks goes to Laurent Charignon for cleanup the last remains of the 'write'
method.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:49 -0800] rev 27275
ui: add a 'deprecwarn' helper to issue deprecation warnings
As discussed on the list, we are adding an official way to keep old API around
for a short time in order to help third party developer to catch up. The
deprecated API will issue developer warning (issued by default during test runs)
to warn extensions authors that they need to upgrade their code without
instantaneously breaking tool chains and normal users.
The version is passed as an explicit argument so that developer think about it
and a potential future script can automatically check for it.
This is not build as a decorator because accessing the 'ui' instance will likely
be different each time. The message is also free form because deprecated API are
replaced in a variety of ways. I'm not super happy about the final rendering of
that message, but this is a developer oriented warning and I would like to move
forward.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:33 -0800] rev 27274
ui: add a 'stacklevel' argument to 'develwarn'
This allows helper functions (like deprecation warning) to prepare a devel
warning for higher up in the stack. The argument is named after the one in the
Python's 'warning,warn' function.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:28:35 +0900] rev 27273
import-checker: tell which symbol causes "direct symbol import"
This would be sometimes useful to understand why import-checker.py complains
about it.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:18:19 +0900] rev 27272
import-checker: allow absolute imports of sub modules from local packages
Before this patch, import-checker.py didn't know if a name in ImportFrom
statement are module or not. Therefore, it complained the following example
did "direct symbol import from mercurial".
# hgext/foo.py
from mercurial import hg
This patch reuses the dict of local modules to filter out sub-module names.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 04 Dec 2015 14:24:45 -0800] rev 27271
manifest: use 't' for tree manifest flag
We currently use 'd' to indicate that a manifest entry is a
directory. Let's switch to 't', since that's not a valid hex digit and
therefore easier to spot in the raw manifest data.
This will break any existing repos with tree manifests, but it's still
an experimental feature and there are probably only a few test repos
in existence with 'd' flags.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:06:03 -0800] rev 27270
test: update the docstring of 'test-devel-warnings.t' extension
We are testing more than just locks now.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 17:52:50 -0800] rev 27269
setup.py: don't rewrite @LIBDIR@ when creating wheels
This is necessary to produce wheels that install properly. More
details are captured in an in-line comment.
After this patch, produced wheels can be installed via `pip install`
and appear to "just work," including on Windows.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 04 Dec 2015 00:24:48 -0800] rev 27268
setup.py: attempt to build and install hg.exe on Windows
Currently, packaging Mercurial on Windows will produce a
Scripts\hg Python script and a Scripts\hg.bat batch script. The
py2exe distribution contains a hg.exe which loads a Python
interpretter and invokes the "hg" Python script. Running a
exe directly has benefits over batch scripts because batch
scripts do things like muck around with command arguments.
This patch implements a custom "build_scripts" command which
attempts to build hg.exe on Windows. If hg.exe is built, it is
marked as a "script" file and installed into the Scripts\
directory on Windows. Since hg.exe is redundant and better than
hg.bat, if hg.exe is built, hg.bat is not installed.
Since some environments don't support compiling C programs,
we treat hg.exe as optional and catch failures building it. This
is not ideal. However, I reckon most Windows users will not be
installing Mercurial from source: they will get it from the MSI
installer or via `pip install Mercurial`, which will download a
wheel that has hg.exe in it. So, I don't think this is a big deal.
Andrew Halberstadt <ahalberstadt@mozilla.com> [Thu, 03 Dec 2015 23:01:59 -0500] rev 27267
merge.graft: add option to keep second parent
Currently merge.graft re-writes the dirstate so only a single
parent is kept. For some cases, like evolving a merge commit,
this behaviour is not desired. More specifically, this is
needed to fix issue4389.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 21:11:04 -0800] rev 27266
ui: support declaring path push urls as sub-options
Power users often want to apply per-path configuration options. For
example, they may want to declare an alternate URL for push operations
or declare a revset of revisions to push when `hg push` is used
(as opposed to attempting to push all revisions by default).
This patch establishes the use of sub-options (config options with
":" in the name) to declare additional behavior for paths.
New sub-options are declared by using the new ``@ui.pathsuboption``
decorator. This decorator serves multiple purposes:
* Declaring which sub-options are registered
* Declaring how a sub-option maps to an attribute on ``path``
instances (this is needed to `hg paths` can render sub-options
and values properly)
* Validation and normalization of config options to attribute
values
* Allows extensions to declare new sub-options without monkeypatching
* Allows extensions to overwrite built-in behavior for sub-option
handling
As convenient as the new option registration decorator is, extensions
(and even core functionality) may still need an additional hook point
to perform finalization of path instances. For example, they may wish
to validate that multiple options/attributes aren't conflicting with
each other. This hook point could be added later, if needed.
To prove this new functionality works, we implement the "pushurl"
path sub-option. This option declares the URL that `hg push` should
use by default.
We require that "pushurl" is an actual URL. This requirement might be
controversial and could be dropped if there is opposition. However,
objectors should read the complicated code in ui.path.__init__ and
commands.push for resolving non-URL values before making a judgement.
We also don't allow #fragment in the URLs. I intend to introduce a
":pushrev" (or similar) option to define a revset to control which
revisions are pushed when "-r <rev>" isn't passed into `hg push`.
This is much more powerful than #fragment and I don't think #fragment
is useful enough to continue supporting.
The [paths] section of the "config" help page has been updated
significantly. `hg paths` has been taught to display path sub-options.
The docs mention that "default-push" is now deprecated. However, there
are several references to it that need to be cleaned up. A large part
of this is converting more consumers to the new paths API. This will
happen naturally as more path sub-options are added and more and more
components need to access them.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 12:31:46 -0800] rev 27265
ui: pass ui instance to path.__init__
It will be used in a subsequent patch.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 11:49:02 -0800] rev 27264
ui: store pushloc as separate attribute
The magic @property is going to interfere with the ability to print
path sub-options. We only access it in one location and it is trivial
to in-line, so do that.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 23:37:46 -0800] rev 27263
commands: add debugdeltachain command
We have debug commands for displaying overall revlog statistics
(debugrevlog) and for dumping a revlog index (debugindex). As part
of investigating various aspects of revlog behavior and performance,
I found it important to have an understanding of how revlog
delta chains behave in practice.
This patch implements a "debugdeltachain" command. For each revision
in a revlog, it dumps information about the delta chain. Which delta
chain it is part of, length of the delta chain, distance since base
revision, info about base revision, size of the delta chain, etc. The
generic formatting facility is used, which means we can templatize
output and get machine readable output like JSON.
This command has already uncovered some weird history in
mozilla-central I didn't know about. So I think it's valuable.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Oct 2015 19:56:39 +0100] rev 27262
histedit: pick an appropriate base changeset by default (BC)
Previously, `hg histedit` required a revision argument specifying which
revision to use as the base for the current histedit operation. There
was an undocumented and experimental "histedit.defaultrev" option that
supported defining a single revision to be used if no argument is
passed.
Mercurial knows what changesets can be edited. And in most scenarios,
people want to edit this history of everything on the current head that
is rewritable. Making histedit do this by default and not require
an explicit argument or additional configuration is a major usability
win and will enable more people to use histedit.
This patch changes the behavior of the experimental and undocumented
"histedit.defaultrev" config option to select an appropriate base
revision by default. Comprehensive tests exercising the edge cases
in the new, somewhat complicated default revset have been added.
Surprisingly, no tests broke. I guess we were never testing the
behavior with no ANCESTOR argument (it used to fail with
"abort: histedit requires exactly one ancestor revision"). The new
behavior is much more user friendly.
The functionality for choosing the default base revision has been
moved to destutil.py, where it can easily be modified by extensions.
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:50:13 +0900] rev 27261
rebase: remove extra "if" from check of collapsing named branches
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:48:22 +0900] rev 27260
rebase: drop redundant functions to keep branch and graft source explicitly
All entries in extra dict are propagated by default since 88fde8db5307.
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Dec 2015 23:41:11 +0900] rev 27259
color: drop useless override of ui.popbuffer()
Because labels are applied at write() time since 717b75ae5bb0,
colorui.popbuffer() is useless and it doesn't update _bufferapplylabels
correctly. Removing it should fix the problem.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Dec 2015 14:22:15 -0800] rev 27258
repoview: bypass changelog method to computed cache key
Getting the data necessary for the cache key using the changelog/revlog method
adds a significant overhead. Given how simple the underlying implementation is
and often this code is ran, it makes sense to violate layering and directly
compute the data.
Testing `hg log` on Mozilla-central, this reduce the time spent on changelog
cache validation by an extra half:
before: 12.2s of 69s
after: 6.1s of 62s
Total speed up from this patch and it's parent is 3x
(With stupid python profiler overhead)
The global speedup without profiler overhead is still there,
Before: 51s
After: 39s (-23%)
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Dec 2015 14:04:24 -0800] rev 27257
repoview: stop recomputing cached key in all case
As explained in the comment, we were computing the key of the cache value every
time because of some obscure MQ test failure. I've dropped that code and ran the
test again that failure is gone. I assume some transaction cleanup got rid of
it.
So we are dropping that code. This provide a significant speedup.
Testing `hg log` on Mozilla-central this reduce the time spent on changelog
cache validation by a third:
before: 19.5s of 80s
after: 12.2s of 69s
(With stupid python profiler overhead)