- Jul 02, 2016
-
-
Gregory Szorc authored
I should have ran the entire test suite on Python 2.6. Since the hostname matching tests are implemented in Python (not .t tests), it didn't uncover this warning. I'm not sure why - warnings should be printed regardless. This is possibly a bug in the test runner. But that's for another day...
-
- Jul 01, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jun 27, 2016
-
-
Gregory Szorc authored
sslutil contains its own hostname matching logic. CPython has code for the same intent. However, it is only available to Python 2.7.9+ (or distributions that have backported 2.7.9's ssl module improvements). This patch effectively imports CPython's hostname matching code from its ssl.py into sslutil.py. The hostname matching code itself is pretty similar. However, the DNS name matching code is much more robust and spec conformant. As the test changes show, this changes some behavior around wildcard handling and IDNA matching. The new behavior allows wildcards in the middle of words (e.g. 'f*.com' matches 'foo.com') This is spec compliant according to RFC 6125 Section 6.5.3 item 3. There is one test where the matcher is more strict. Before, '*.a.com' matched '.a.com'. Now it doesn't match. Strictly speaking this is a security vulnerability.
-
Gregory Szorc authored
CPython has a more comprehensive test suite for it's built-in hostname matching functionality. This patch adds its tests so we can improve our hostname matching functionality. Many of the tests have different results from CPython. These will be addressed in a subsequent commit.
-
- Jul 01, 2016
-
-
Wagner Bruna authored
-
- Jun 16, 2016
-
-
Mike Miller authored
The subpaths substitution logic first attempts to match the absolute repository path, then the relative subrepository path if that failed.
-
- Jun 07, 2016
-
-
Henrik Stuart authored
Prior to revision 2a3f24786d09, largefiles were saved in the local repository, even if it was using the share extension. After that change, all largefiles are now stored in the shared repository. However, the backward compatibility for existing largefiles already placed in the local repository was never tested, and has been broken since.
-
- Jun 02, 2016
-
-
Matt Mackall authored
Now that we extend matches backwards in the inner loop, the final adjustment has no effect. (A similar extension for the forward direction is trickier and has less benefit.)
-
Matt Mackall authored
For very large diffs that have large numbers of identical lines (JSON dumps) that also have large blocks of identical text, bdiff could become confused about which block matches which because it can only match very limited regions. The result is very large diffs for small sets of edits. The earlier recursion rebalancing fix made this behavior more frequent because it's now more prone to match block 1 to block 2. One frequent user of large JSON files reported being unable to pass the resulting diffs through their code review system. Prior to this change, bdiff would calculate the length of a match at (i, j) as 1 + length found at (i-1, j-1). With large number of popular (ignored) lines, this often meant matches couldn't be extended backwards at all and thus all matching regions were very small. Disabling the popularity threshold is not an option because it brings back quadratic behavior. Instead, we extend a match backwards until we either found a previously discovered match or we find a mismatching line. This thus successfully bridges over any popular lines inside and before a matching region. The larger regions then significant reduce the probability of confusion.
-
Danek Duvall authored
Rather than sometimes using a complicated shell construct to dump pwned.txt (if it wasn't expected to exist, but might, if something were broken) or just cat (if it was expected to exist), just use the "f" utility, which will be consistent in its behavior across different platforms. Also make sure that *something* gets put into pwned.txt, even if we ended up typoing the message variable.
-
- Jun 01, 2016
-
-
Mads Kiilerich authored
Usually, the heads will have the same ordering in handlecheckheads. Insisting on the same ordering is however an unnecessary constraint that in some custom cases can cause pushes to fail even though the actual heads didn't change. This caused production issues for us in combination with the current version of https://bitbucket.org/Unity-Technologies/hgwebcachingproxy/ .
-
Matt Mackall authored
-
Matt Mackall authored
-
- May 27, 2016
-
-
Danek Duvall authored
Having a single "pwned" message which may or may not be emitted during the tests for CVE-2016-3068 leads to extra confusion. Allow each test to emit a more detailed message based on what the expectations are. In both cases, we expect a version of git which has had the vulnerability plugged, as well as a version of mercurial which also knows about GIT_ALLOW_PROTOCOL. For the first test, we make sure GIT_ALLOW_PROTOCOL is unset, meaning that the ext-protocol subrepo should be ignored; if it isn't, there's either a problem with mercurial or the installed copy of git. For the second test, we explicitly allow ext-protocol subrepos, which means that the subrepo will be accessed and a message emitted confirming that this was, in fact, our intention.
-
Danek Duvall authored
The "pwned" message from this test gets gets sent to stderr, and so may get emitted in different places from run to run in the rest of mercurial's output. This patch forces the message to go to a specific file instead, whose existence and contents we can examine at a stable point in the test's execution.
-
Danek Duvall authored
When diffing against an empty file, Solaris diff uses 1 to designate the first line of the empty file (either -1,0 on the left or +1,0 on the right) while GNU diff uses 0 (-0,0 and +0,0). We use a glob here to make sure the test passes with either toolchain. I've not added tests to check-code because there are scads of places in the tests where the GNU format is used due to that being the format that "hg diff" and "hg export" use, and changing those to use globs seems wrong.
-
Javi Merino authored
-
- May 24, 2016
-
-
liscju authored
Before 'hg push -B .' on new remote head complained with: abort: push creates new remote head ... It was because _nowarnheads was not expanding active bookmark name, so it didn't add active bookmark "proper" name to no warn heads list.
-
- May 12, 2016
-
-
Laurent Charignon authored
When we remove a changeset from the changelog, the phase cache must be invalidated, otherwise it could refer to changesets that are no longer in the repo. To reproduce the failure, I created an extension querying the phase cache after the strip transaction is over. To do that, I stripped two commits with a bookmark on one of them to force another transaction (we open a transaction for moving bookmarks) after the strip transaction. Without the fix in this patch, the test leads to a stacktrace showing the issue: repair.strip(ui, repo, revs, backup) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/repair.py", line 205, in strip tr.close() File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/transaction.py", line 44, in _active return func(self, *args, **kwds) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/transaction.py", line 490, in close self._postclosecallback[cat](self) File "$TESTTMP/crashstrip2.py", line 4, in test [repo.changelog.node(r) for r in repo.revs("not public()")] File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/changelog.py", line 337, in node return super(changelog, self).node(rev) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/revlog.py", line 377, in node return self.index[rev][7] IndexError: revlog index out of range The situation was encountered in inhibit (evolve's repo) where we would crash following the volatile set invalidation submitted by Augie in e6f490e32863. Before his patch the issue was masked as we were not accessing the phasecache after stripping a revision. This bug uncovered another but in histedit (see explanation in issue5235). I changed the histedit test accordingly to avoid fixing two things at once.
-
- May 19, 2016
-
-
Mateusz Kwapich authored
If you have just executable-bit change and amend it twice it will vanish: * After the first amend the commit will have the proper executable bit set in manifest but it won't have the the file on the list of files in changelog. * The second amend will read the wrong list of files from changelog and it will copy the manifest entry from parent for this file. * Voila! The change is lost. This change repairs the bug in localrepo causing this and adds a test for it.
-
- May 20, 2016
-
-
Katsunori FUJIWARA authored
GNU grep (2.21-2 or later) assumes that input is encoded in LC_CTYPE, and input is binary if it contains byte sequence not valid for that encoding. For example, if locale is configured as C, a byte setting most significant bit (MSB) makes such GNU grep show "Binary file <FILENAME> matches" message instead of matched lines unintentionally. This behavior is recognized as a bug, and fixed in GNU grep 2.25-1 or later. But some distributions are shipped with such buggy version (e.g. Ubuntu xenial, which is used by launchpad buildbot). http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19230 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800670 http://packages.ubuntu.com/xenial/grep This causes failure of test-commit-interactive.t, which applies grep on CP932 byte sequence since 1111e84de635. But, explicit setting LC_CTYPE for CP932 might cause another problem, because it can't be assumed that all environment running Mercurial tests allows arbitrary locale setting. To resolve this issue, this patch escapes bytes setting MSB in input of grep. For this purpose: - str.encode('string-escape') isn't useful, because it escapes also control code (less than 0x20), and makes EOL handling complicated - "f --hexdump" isn't useful, because it isn't line-oriented - "sed -n" seems reasonable, but "sed" itself sometimes causes portability issue, too (e.g. 900767dfa80d or afb86ee925bf) This patch is posted with "stable" flag, because 1111e84de635 is on stable branch.
-
- May 16, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- May 12, 2016
-
-
Katsunori FUJIWARA authored
Before this patch, "hg help topic.section" might show unexpected section of help topic in some encoding. It applies str.lower() instead of encoding.lower(str) on translated message to search section case-insensitively, but some encoding uses 0x41(A) - 0x5a(Z) as the second or later byte of multi-byte character (for example, ja_JP.cp932), and str.lower() causes unexpected result. To search section of help topic by translated section name correctly, this patch replaces str.lower() by encoding.lower(str) for both query string (in commands.help()) and translated help text (in minirst.getsections()).
-
Katsunori FUJIWARA authored
Before this patch, patch.filterpatch() shows meaningless translation of help message for chunk selection in some encoding. It applies str.lower() instead of encoding.lower(str) on translated message, but some encoding uses 0x41(A) - 0x5a(Z) as the second or later byte of multi-byte character (for example, ja_JP.cp932), and str.lower() causes unexpected result. To show lower-ed translated message correctly, this patch replaces str.lower() by encoding.lower(str).
-
- May 09, 2016
-
-
Matt Harbison authored
It previously aborted saying the help section wasn't found. Credit to Yuya for figuring out the fix.
-
- May 06, 2016
-
-
Sean Farley authored
This is needed so that launchpad and friends have a unique version number for each distroseries (trusty, wily, xenial, etc). It was discovered when trying to upload 3.8 to launchpad.
-
- May 01, 2016
-
-
Sean Farley authored
-
Sean Farley authored
Debian maintainers already have this and lintian warns us about not listing 'wish' as a dependency or suggestion so this patch does indeed just that. The issue, by the way, is that we are shipping hgk (which is written in tcl/tk) so we should be good citizens and list wish (a meta package for tcl/tk) as a dependency.
-
- May 07, 2016
-
-
Sean Farley authored
This corrects a warning from lintian that we're shipping an executable without a man page. Since there is a doc string in the text, let's use that for the man page.
-
- May 06, 2016
-
-
Matt Mackall authored
The progress bar was being cleared on every write(), regardless of whether it was currently displayed. This could foul up the display of any writes that didn't include a linebreak. In particular, the win32 mode of the color extension was turning single prompt string writes into two writes, and the resulting clear/write/clear/write pattern was making the prompt invisible. We fix this by insisting that we have shown a progress bar and haven't just cleared it (setting lastprint to 0). Conveniently, the test suite already had instances of duplicate clears.. that are now cleared up.
-
- May 05, 2016
-
-
Pierre-Yves David authored
Regular users are not supposed to be exposed to the API deprecation warnings. We now only issue them when the developper warnings are enabled.
-
Augie Fackler authored
This corrects a regression introduced during the 3.7 cycle, but which went undetected due to the surviving-but-deprecated write() method on bmstore.
-
Augie Fackler authored
This hasn't been testing anything since partway through the 3.7 cycle due to unrelated refactoring. Sadly, the behavior it was trying to prevent reemerged in the codebase at that time. A fix is in the next patch, because proving that the fix was actually correct ended up being trickier than I expected.
-
Mike Hommey authored
getbundle was requesting the "phase" namespace instead of the "phases" namespace, which led to the client still requesting the phases separately after getbundle finished.
-
- May 01, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Apr 07, 2016
-
-
Blake Burkhart authored
Fixes CVE-2016-3105 (1/1). Previously, it was possible for the repository path passed to git-ls-remote to be misinterpreted as a URL. Always passing an absolute path to git is a simple way to avoid this.
-
- May 01, 2016
-
-
Matt Mackall authored
-