Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:55:38 +0100] rev 30903
unbundle: add a small comment to tag the bundle1 case as such
This makes the code clearer to understand for someone new to it (or rusted)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Feb 2017 10:51:04 +0100] rev 30902
unbundle: add a small comment to clarify the 'check_heads' call
Bundle2 has its own mechanisms to check for heads (and other) changes, so push
using bundle2 is relying on the "check:heads" bundle part of unbundle and the
'check_heads' call is not checking anything. We add a small comment to make
this clearer.
Simon Farnsworth <simonfar@fb.com> [Thu, 02 Feb 2017 11:17:36 -0800] rev 30901
pager: don't terminate with extreme prejudice on SIGPIPE (BC)
The default SIGPIPE handler causes Mercurial to exit immediately, without
running any Python cleanup code (except and finally blocks, atexit handlers
etc). This creates problems if you want to do something at exit.
If we need a different exit code for broken pipe from pager, then we should
code that ourselves in Python; this appears to have been cargo-culted from
the fork implementation of pager that's no longer used, where it was needed
to stop Broken Pipe errors appearing on the user's terminal.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Jan 2017 10:48:55 -0800] rev 30900
verify: replace _validpath() by matcher
The verifier calls out to _validpath() to check if it should verify
that path and the narrowhg extension overrides _validpath() to tell
the verifier to skip that path. In treemanifest repos, the verifier
calls the same method to check if it should visit a
directory. However, the decision to visit a directory is different
from the condition that it's a matching path, and narrowhg was working
around it by returning True from its _validpath() override if *either*
was true.
Similar to how one can do "hg files -I foo/bar/ -X foo/" (making the
include pointless), narrowhg can be configured to track the same
paths. In that case match("foo/bar/baz") would be false, but
match.visitdir("foo/bar/baz") turns out to be true, causing verify to
fail. This may seem like a bug in visitdir(), but it's explicitly
documented to be undefined for subdirectories of excluded
directories. When using treemanifests, the walk would not descend into
foo/, so verification would pass. However, when using flat manifests,
there is no recursive directory walk and the file path "foo/bar/baz"
would be passed to _validpath() without "foo/" (actually without the
slash) being passed first. As explained above, _validpath() would
return true for the file path and "hg verify" would fail.
Replacing the _validpath() method by a matcher seems like the obvious
fix. Narrowhg can then pass in its own matcher and not have to
conflate the two matching functions (for dirs and files). I think it
also makes the code clearer.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 01 Feb 2017 08:47:27 -0800] rev 30899
rebase: fix code comment to refer to right issue (4504, not 4505)
The comment was introduced in 8a544fb645bb (rebase: ensure rebase
revision remains visible (issue4504), 2015-01-27), which mentions the
right issue in the description.
Kevin Bullock <kbullock+mercurial@ringworld.org> [Wed, 01 Feb 2017 11:30:26 -0600] rev 30898
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Apr 2017 11:36:39 -0700] rev 30897
repair: use rawvfs when copying extra store files
If we use the normal vfs, store encoding will be applied when we
.join() the path to be copied. This results in attempting to copy
a file that (likely) doesn't exist. Using the rawvfs operates on
the raw file path, which is returned by vfs.readdir().
Users at Mozilla are encountering this, as I've instructed them to
run `hg debugupgraderepo` to upgrade to generaldelta. While Mercurial
shouldn't deposit any files under .hg/store that require encoding, it
is possible for e.g. .DS_Store files to be created by the operating
system.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Apr 2017 11:35:29 -0700] rev 30896
tests: add test demonstrating buggy path handling
`hg debugupgraderepo` is currently buggy with regards to path
handling when copying files in .hg/store/. Specifically, it applies
the store filename encoding to paths instead of operating on raw
files.
This commit adds a test demonstrating the buggy behavior.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Apr 2017 11:35:00 -0700] rev 30895
repair: iterate store files deterministically
An upcoming test will add a 2nd file. Since readdir() is
non-deterministic, add a sorted() to make traversal deterministic.
Augie Fackler <raf@durin42.com> [Mon, 03 Apr 2017 17:34:24 -0400] rev 30894
Added signature for changeset ed5b25874d99
Augie Fackler <raf@durin42.com> [Mon, 03 Apr 2017 17:34:22 -0400] rev 30893
Added tag 4.1.2 for changeset ed5b25874d99
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 23 Mar 2017 19:54:59 -0700] rev 30892
changegroup: store old heads as a set
Previously, the "oldheads" variable was a list. On a repository at
Mozilla with 46,492 heads, profiling revealed that list membership
testing was dominating execution time of applying small changegroups.
This patch converts the list of old heads to a set. This makes
membership testing significantly faster. On the aforementioned
repository with 46,492 heads:
$ hg unbundle <file with 1 changeset>
before: 18.535s wall
after: 1.303s
Consumers of this variable only check for truthiness (`if oldheads`),
length (`len(oldheads)`), and (most importantly) item membership
(`h not in oldheads` - which occurs twice). So, the change to a set
should be safe and suitable for stable.
The practical effect of this change is that changegroup application
and related operations (like `hg push`) no longer exhibit an O(n^2)
CPU explosion as the number of heads grows.
Simon Farnsworth <simonfar@fb.com> [Mon, 20 Mar 2017 04:36:55 -0700] rev 30891
subrepo: move prompts out of the if (issue5505)
Prompts weren't available in the else clause
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Mar 2017 12:33:15 -0700] rev 30890
exchange: use v2 bundles for modern compression engines (issue5506)
Previously, `hg bundle zstd` on a non-generaldelta repo would
attempt to use a v1 bundle. This would fail because zstd is not
supported on v1 bundles.
This patch changes the behavior to automatically use a v2 bundle
when the user explicitly requests a bundlespec that is a compression
engine not supported on v1. If the bundlespec is <engine>-v1, it is
still explicitly rejected because that request cannot be fulfilled.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Mar 2017 12:23:56 -0700] rev 30889
exchange: reject new compression engines for v1 bundles (issue5506)
Version 1 bundles only support a fixed set of compression engines.
Before this change, we would accept any compression engine for v1
bundles, even those that may not work on v1. This could lead to
an error.
We define a fixed set of compression engines known to work with v1
bundles and we add checking to ensure a newer engine (like zstd)
won't work with v1 bundles.
I also took the liberty of adding test coverage for unknown compression
names because I noticed we didn't have coverage of it before.