Durham Goode <durham@fb.com> [Mon, 11 Jul 2016 13:40:02 -0700] rev 29506
share: don't recreate the source repo each time
Previously, every time you asked for the source repo of a shared working copy it
would recreate the repo object, which required calling reposetup. With certain
extension enabled, this can be quite expensive, and it can happen many times
(for instance, share attaches a post transaction hook to update bookmarks that
triggers this).
The fix is to just cache the repo object instead of constantly recreating it.
Maciej Fijalkowski <fijall@gmail.com> [Mon, 11 Jul 2016 10:44:18 +0200] rev 29505
setup: prepare for future cffi modules by adding placeholder in setup
Martijn Pieters <mjpieters@fb.com> [Fri, 08 Jul 2016 16:48:38 +0100] rev 29504
journal: add support for seaching by pattern
If a pattern is used, include the entry name in the output, to make it clear
what name was matched.
Martijn Pieters <mjpieters@fb.com> [Mon, 11 Jul 2016 14:45:41 +0100] rev 29503
journal: add share extension support
Rather than put everything into one journal file, split entries up in *shared*
and *local* entries. Working copy changes are local to a specific working copy,
so should remain local only. Other entries are shared with the source if so
configured when the share was created.
When unsharing, any shared journale entries are copied across.
Martijn Pieters <mjpieters@fb.com> [Mon, 11 Jul 2016 13:39:24 +0100] rev 29502
journal: add dirstate tracking
Note that now the default action for `hg journal` is to list the working copy
history, not all bookmarks. In its place is the `--all` switch which lists all
name changes recorded, including the name for which the change was recorded on
each line.
Locking is switched to using a dedicated lock to avoid issues with the dirstate
being written during wlock unlocking (you can't re-lock during that process).
Matt Mackall <mpm@selenic.com> [Mon, 11 Jul 2016 08:54:13 -0500] rev 29501
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 06 Jul 2016 21:16:00 -0700] rev 29500
sslutil: try to find CA certficates in well-known locations
Many Linux distros and other Nixen have CA certificates in well-defined
locations. Rather than potentially fail to load any CA certificates at
all (which will always result in a certificate verification failure),
we scan for paths to known CA certificate files and load one if seen.
Because a proper Mercurial install will have the path to the CA
certificate file defined at install time, we print a warning that
the install isn't proper and provide a URL with instructions to
correct things.
We only perform path-based fallback on Pythons that don't know
how to call into OpenSSL to load the default verify locations. This
is because we trust that Python/OpenSSL is properly configured
and knows better than Mercurial. So this new code effectively only
runs on Python <2.7.9 (technically Pythons without the modern ssl
module).
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 06 Jul 2016 20:46:05 -0700] rev 29499
sslutil: issue warning when unable to load certificates on OS X
Previously, failure to load system certificates on OS X would lead
to a certificate verify failure and that's it. We now print a warning
message with a URL that will contain information on how to configure
certificates on OS X.
As the inline comment states, there is room to improve here. I think
we could try harder to detect Homebrew and MacPorts installed
certificate files, for example. It's worth noting that Homebrew's
openssl package uses `security find-certificate -a -p` during package
installation to export the system keychain root CAs to
etc/openssl/cert.pem. This is something we could consider adding
to setup.py. We could also encourage packagers to do this. For now,
I'd just like to get this warning (which matches Windows behavior)
landed. We should have time to improve things before release.
skarlage <skarlage@fb.com> [Thu, 30 Jun 2016 08:38:19 -0700] rev 29498
revert: don't backup if no files reverted in interactive mode (issue4793)
When reverting interactively, we always backup files before prompting the user
to find out if they actually want to revert them. This can create spurious
*.orig files if a user enters an interactive revert session and then doesn't
revert any files. Instead, we should only backup files that are actually being
touched.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 05 Jul 2016 07:25:51 +0900] rev 29497
perf: define command annotation locally for Mercurial earlier than 3.1
Before this patch, using cmdutil.command() for "@command" annotation
prevents perf.py from being loaded by Mercurial earlier than 1.9 (or
2daa5179e73f), because cmdutil.command() isn't available in such
Mercurial, even though there are some code paths for Mercurial earlier
than 1.9.
For example, setting "_prereadsize" attribute in perfindex() and
perfnodelookup() is effective only with hg earlier than 1.8 (or
61c9bc3da402).
In addition to it, "norepo" option of command annotation has been
available since 3.1 (or 75a96326cecb), and this is another blocker for
loading perf.py with earlier Mercurial.
============ ============ ======
command of
hg version cmdutil norepo
============ ============ ======
3.1 or later o o
1.9 or later o x
earlier x x
============ ============ ======
This patch defines "command()" for annotation locally as below:
- define wrapper of existing cmdutil.command(), if cmdutil.command()
doesn't support "norepo"
(for Mercurial earlier than 3.1)
- define full command() locally with minimum function, if
cmdutil.command() isn't available at runtime
(for Mercurial earlier than 1.9)
This patch also defines parsealiases() locally without examining
whether it is available or not, because it is small enough to define
locally.