Sat, 10 Jan 2015 12:56:38 +0900 revset: allow rev(-1) to indicate null revision (BC) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jan 2015 12:56:38 +0900] rev 23954
revset: allow rev(-1) to indicate null revision (BC) This can simplify the conversion from numeric revision to string. Without it, we have to handle -1 specially because repo['-1'] != repo[-1]. The -1 revision is not officially documented, but this change makes sense assuming that "rev(%d)" exists for scripting or third-party tools.
Fri, 23 Jan 2015 20:30:49 -0800 extensions: don't quit loading extensions in the middle if traceback is on stable
Siddharth Agarwal <sid0@fb.com> [Fri, 23 Jan 2015 20:30:49 -0800] rev 23953
extensions: don't quit loading extensions in the middle if traceback is on This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if loading an extension failed when --traceback was on, then at some point morphed into a 'return 1' in a function that otherwise returns nothing. At this point, if ui.traceback is enabled and if loading an extension fails for whatever reason, including one as innocent as it not being present, we leave any extensions loaded so far in a bogus half-initialized state. That doesn't really make any sense.
Fri, 23 Jan 2015 17:47:04 -0600 test-hgweb: fix shutdown race stable
Matt Mackall <mpm@selenic.com> [Fri, 23 Jan 2015 17:47:04 -0600] rev 23952
test-hgweb: fix shutdown race Logfiles weren't necessarily being flushed before being read.
Thu, 22 Jan 2015 00:08:13 +0900 tests: invoke hg command indirectly from shell script to run on Windows stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:08:13 +0900] rev 23951
tests: invoke hg command indirectly from shell script to run on Windows Before this patch, test-tag.t can't run successfully on Windows, because: - quoted hg command ('"hg"') prevents "hg.bat" from working correctly (only at testing with pure Python build) "%~f0" and "%~dp0hg" in "hg.bat" cause unexpected result in this case. BTW, quoted "\path\to\hg" works correctly. - "`pwd`" in the command line is expanded unexpectedly not "C:\path\to\TESTTMP" but "C;C:\path\to\TESTTMP"
Wed, 21 Jan 2015 15:23:13 -0800 log: evaluate filesets on working copy, not its parent stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jan 2015 15:23:13 -0800] rev 23950
log: evaluate filesets on working copy, not its parent When running "hg log 'set:added()'", we create two matchers: one used for producing the revset and one used for finding files to match. In 1fd352aa08fc (graphlog: evaluate FILE/-I/-X filesets on the working dir, 2012-02-26), we started passing a revision argument along from what's currently in cmdutil._makelogrevset() to revset._matchfiles(). When the revision was an empty string, it referred to the working copy. This was subtly done with "repo[rev or None]". Then, in f2aeff8a87b6 (revset: avoid recalculating filesets, 2014-10-22), that conversion from empty string to None was lost. Note that repo[''] is equivalent to repo['.'], not repo[None]. The consequence of this, to the user, is that when running "hg log 'set:added()'", the file matcher matches files added in the working copy, while the revset matcher matches revisions that touch files added in the parent of the working copy. As a result, only revisions that touch any files added in the parent of the working copy will be considered, but they will only be included if they also touch files added in the working copy. Fix the bug by converting '' to None again, but make it a little more explicit this time (plus, we now have tests for it).
Wed, 21 Jan 2015 15:40:24 -0800 fileset: add tests of generated working copy states stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 21 Jan 2015 15:40:24 -0800] rev 23949
fileset: add tests of generated working copy states
Fri, 23 Jan 2015 15:55:36 -0500 parsers: avoid leaking several PyObjects in index_stats stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:55:36 -0500] rev 23948
parsers: avoid leaking several PyObjects in index_stats Found with cpychecker.
Fri, 23 Jan 2015 15:50:40 -0500 parsers: don't leak a reference to raise_revlog_error on success stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:50:40 -0500] rev 23947
parsers: don't leak a reference to raise_revlog_error on success Found with cpychecker.
Fri, 23 Jan 2015 15:48:18 -0500 parsers: don't leak a tuple in pack_dirstate stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:48:18 -0500] rev 23946
parsers: don't leak a tuple in pack_dirstate Spotted with cpychecker.
Fri, 23 Jan 2015 15:41:46 -0500 parsers.c: fix a memory leak in index_commonancestorsheads stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:41:46 -0500] rev 23945
parsers.c: fix a memory leak in index_commonancestorsheads Spotted with cpychecker.
Fri, 23 Jan 2015 15:33:27 -0500 parsers: avoid leaking obj in index_ancestors stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:33:27 -0500] rev 23944
parsers: avoid leaking obj in index_ancestors PySequence_GetItem returns a new reference. Found with cpychecker.
Fri, 23 Jan 2015 15:30:21 -0500 parsers: don't leak references to sys et al in check_python_version stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:30:21 -0500] rev 23943
parsers: don't leak references to sys et al in check_python_version Found with cpychecker.
Fri, 23 Jan 2015 15:19:04 -0500 parsers: fix leak of err when asciilower hits a unicode decode error stable
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:19:04 -0500] rev 23942
parsers: fix leak of err when asciilower hits a unicode decode error This is one of many errors detected in parsers.c by cpychecker[1]. I haven't gone through all of them yet. 1: https://gcc-python-plugin.readthedocs.org/en/latest/index.html
Fri, 23 Jan 2015 18:41:37 +0100 largefiles: use 'default' path for pulling largefiles, not 'default-push' stable
Mads Kiilerich <madski@unity3d.com> [Fri, 23 Jan 2015 18:41:37 +0100] rev 23941
largefiles: use 'default' path for pulling largefiles, not 'default-push' The put parameter has been unused since day 0.
Fri, 23 Jan 2015 06:28:28 +0100 osx: patch .pax.gz files in pkg bundles so they extract as root (issue4081) stable
Mads Kiilerich <madski@unity3d.com> [Fri, 23 Jan 2015 06:28:28 +0100] rev 23940
osx: patch .pax.gz files in pkg bundles so they extract as root (issue4081) The packages has to be installed by root but they would be installed insecurely, owned by the uid of the unprivileged user that made the package. The local user with that uid could thus write to /usr/local/bin/hg . bdist_mpkg calls out to pax to create the package, but pax do apparently not have the power to control what it is writing. Instead, patch the pax files and set their uid fields to 0 before they are wrapped in a dmg.
Wed, 21 Jan 2015 15:54:52 -0800 repair._bundle: fix traceback for bad config value stable
Eric Sumner <ericsumner@fb.com> [Wed, 21 Jan 2015 15:54:52 -0800] rev 23939
repair._bundle: fix traceback for bad config value On IRC, rom1dep reported a traceback[1] from setting experimental.strip-bundle2-version to True. This diff catches unexpected values and falls back to the non-experimental bundle1 implementation after issuing a warning. [1] http://gist.tamytro.org/_admin/gists/qXcdQLwtApgy6e3NwWgl
Wed, 21 Jan 2015 21:47:27 +0100 subrepo: correctly add newline for git subrepo diffs stable
Mathias De Maré <mathias.demare@gmail.com> [Wed, 21 Jan 2015 21:47:27 +0100] rev 23938
subrepo: correctly add newline for git subrepo diffs Previously, git subrepo diffs did not have a newline at the end. This caused multiple subrepo diffs to be joined on the same line. Additionally, the command prompt after the diff still contained a part of the diff.
Thu, 22 Jan 2015 00:10:26 +0900 tests: discard useless "(glob)" in "reverting subrepo" lines stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:10:26 +0900] rev 23937
tests: discard useless "(glob)" in "reverting subrepo" lines
Thu, 22 Jan 2015 00:10:26 +0900 check-code.py: avoid warning against "reverting subrepo ..." lines stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:10:26 +0900] rev 23936
check-code.py: avoid warning against "reverting subrepo ..." lines Before this patch, "reverting subrepo subrepo/path" lines in *.t test files require "(glob)", because such lines are recognized as "reverting path/to/managed/file" by "check-code.py". On the other hand, "(glob)" for such "reverting ..." line is recognized as useless by "runt-tests.py", because subrepo paths shown in such lines are always normalized by "util.pconvert". And this causes "no result code from test" warning. As a preparation for discarding "(glob)" from such lines in subsequent patch, this patch avoids warning against them, by adding negative lookahead assertion "(?!subrepo )" to the regexp.
Thu, 22 Jan 2015 00:07:06 +0900 run-tests.py: inherit --pure option from outer run-tests.py execution stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:07:06 +0900] rev 23935
run-tests.py: inherit --pure option from outer run-tests.py execution Before this patch, "test-run-tests.t" doesn't test "run-tests.py" with "--pure", even if outer "run-tests.py" is executed with it. This patch uses not "HG_RUN_TESTS_PURE" but "HGTEST_RUN_TESTS_PURE", because "HG_" prefixed environments are forcibly dropped in "_getenv()". This is also useful to run "run-tests.py" successfully by "run-tests.py --pure" on Windows without any compilation tools (like VisualStudio).
Thu, 22 Jan 2015 00:07:06 +0900 hg.bat: return exit code explicitly for indirect invocation stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:07:06 +0900] rev 23934
hg.bat: return exit code explicitly for indirect invocation When "hg.bat" is invoked via interactive shell "cmd.exe" on Windows, it can store own exit code into ERRORLEVEL correctly, regardless of explicit "exit" statement in it: "cmd.exe" seems to hold ERRORLEVEL updated by the last command in the batch file (= "python hg", in "hg.bat" case). On the other hand, "hg.bat" is invoked indirectly via "subprocess.Popen" (e.g. shell alias, hooks, hgclient and so on), the parent process always receives exit code 0 from spawned "hg.bat": batch files on Windows seem not to be really spawned like as shell scripts on UNIX, but to be executed in the "cmd.exe" process. This patch returns exit code explicitly for indirect invocation. "/b" should be specified for "exit" to prevent "cmd.exe" from being terminated when "hg.bat" is invoked interactively from it.
Thu, 22 Jan 2015 00:03:58 +0900 run-tests.py: execute hghave with same env vars as ones for actual tests stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 22 Jan 2015 00:03:58 +0900] rev 23933
run-tests.py: execute hghave with same env vars as ones for actual tests Before this patch, "run-tests.py" executes "hghave" process without any modifications for environment variables, even though actual tests are executed with LC_ALL, LANG and LANGUAGE explicitly assigned "C". When "run-tests.py" is executed: - with non-"C" locale environment variables on any platforms, or - without any explicit locale environment setting on Windows (only for "outer-repo" feature using "hg root") external commands indirectly executed by "hghave" may show translated messages. This causes incorrect "hghave" result and skipping tests, because some regexp matching of "hghave" expect external commands to show un-translated messages. To prevent external commands from showing translated messages, this patch makes "run-tests.py" execute "hghave" with same environment variables as ones for actual tests. This patch doesn't make "hghave" execute external commands forcibly with LC_ALL, LANG and LANGUAGE explicitly assigned "C", because changing "run-tests.py" is cheaper than changing "hghave": - "os.popen" should be replaced by "subprocess.Popen" or so, and - setting up environment variables should be newly added
Wed, 21 Jan 2015 05:04:48 +0100 osx: use bdist_mpkg.script_bdist_mpkg module instead of bdist_mpkg command stable
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:04:48 +0100] rev 23932
osx: use bdist_mpkg.script_bdist_mpkg module instead of bdist_mpkg command It seems like a default installation of bdist_mpkg makes it available as Python module, but the corresponding executable is placed in a location like /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/bin which is not in $PATH and thus not directly available. 'make osx' would thus fail. Instead, skip the bdist_mpkg executable and invoke it as a Python module. That works out of the box here.
Wed, 21 Jan 2015 05:04:46 +0100 osx: don't launch installer after building it with bdist_mpkg stable
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:04:46 +0100] rev 23931
osx: don't launch installer after building it with bdist_mpkg bdist_mpkg do for some reason default to use the parameter --show ("Open with Installer.app after building") if no parameters are specified. We do not like that. All the important parameters to bdist_mpkg are already specified in setup.py and we don't have any to specify in the Makefile. Instead, specify the parameter '--' which do no harm but will disable the default opening of the installer. This makes it possible to build packages "silently".
Wed, 21 Jan 2015 05:01:01 +0100 osx: update "Read Me" "Important Information" text in the package installer stable
Mads Kiilerich <madski@unity3d.com> [Wed, 21 Jan 2015 05:01:01 +0100] rev 23930
osx: update "Read Me" "Important Information" text in the package installer Nothing fancy here, just making the text less specific and less wrong by not mentioning OS X version and Python versions and wrong URLs.
Tue, 20 Jan 2015 15:05:44 -0800 commit: remove reverse search for copy source when not in parent (issue4476) stable
Ryan McElroy <rmcelroy@fb.com> [Tue, 20 Jan 2015 15:05:44 -0800] rev 23929
commit: remove reverse search for copy source when not in parent (issue4476) Previously, we had weird, nonsensical behavior when committing a file move with a missing source. This removes that weird logic and tests that the bug this strange behavior caused is fixed. Also adds a longish comment to prevent some poor soul from accidentally re-implementing the bug in the future.
Tue, 20 Jan 2015 14:51:11 -0800 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Tue, 20 Jan 2015 14:51:11 -0800] rev 23928
merge with i18n
Sun, 18 Jan 2015 11:16:45 -0200 i18n-pt_BR: synchronized with db8e3f7948b1 stable
Wagner Bruna <wbruna@yahoo.com> [Sun, 18 Jan 2015 11:16:45 -0200] rev 23927
i18n-pt_BR: synchronized with db8e3f7948b1
Sun, 18 Jan 2015 22:21:53 -0500 convert: handle LookupError in mercurial_source.lookuprev() stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 22:21:53 -0500] rev 23926
convert: handle LookupError in mercurial_source.lookuprev() This is in line with the documentation on the base class method, and is related to issue4496 (but doesn't fix the reporter's problem of not mangling other data that matches a revision pattern). Now instead of aborting when there is an ambiguous source rev, it simply won't update the commit comment. A warning message might be nice, but a None return masks whether the problem was no matching revision, or more than one. The only other caller of this is the logic that converts tags, but those are never ambiguous since they are always 40 characters. A test isn't feasible because there simply aren't enough commits in the test suite repos to have an ambiguous identifier that is at least 6 characters long, and it would be too easy for the ambiguity to disappear when unrelated changes are made. Instead, I simply ran 'hg --traceback log -r c' on the hg repo, and handled the error it threw.
Sun, 18 Jan 2015 22:24:14 -0800 color: add missing 'dim' in _effects stable
Sean Farley <sean.michael.farley@gmail.com> [Sun, 18 Jan 2015 22:24:14 -0800] rev 23925
color: add missing 'dim' in _effects It seems that this has been missing for people running in 'ansi' mode.
Sat, 17 Jan 2015 15:03:41 -0800 diff: use binary diff when copy source is binary stable
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Jan 2015 15:03:41 -0800] rev 23924
diff: use binary diff when copy source is binary When a binary source has been copied or renamed into a non-binary file, we don't check whether the copy source was binary. There is a code comment explaining that a git mode will be forced anyway in order to capture the copy record (i.e. losedatafn() will be called). This is true, but forcing git mode is not the only effect binary files have: when git mode was already requested, we use the binary-ness to tell us whether to use a regular unified diff or a git binary diff. The user sees this as a "Binary file $file has changed" instead of the binary
Sun, 18 Jan 2015 15:15:40 -0500 largefiles: fix commit of a directory with no largefile changes (issue4330) stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 15:15:40 -0500] rev 23923
largefiles: fix commit of a directory with no largefile changes (issue4330) When a directory is named in the commit file list, the previous behavior was to walk the list, and if no normal files in the directory were also named, add the corresponding standin for each largefile in that directory. The directory is then dropped from the list, so that committing a directory with no normal file changes works. It then added the corresponding standin directory for the first largefile seen, by prefixing it with '.hglf/'. The latter is unnecessary since each affected largefile is explicitly referenced by its standin in the list. It also caused an abort if there were no changed largefiles in the directory, because none of its standins changed: abort: .hglf/foo/bar: no match under directory! This list of files is used to tweak a matcher in lfutil.updatestandinsbymatch(), which is what is passed to commit(). The status() call that is ultimately done in the commit code with this matcher seems to have some OS specific differences. It is not necessary to append '.' for Windows to run the largefiles tests cleanly. But if '.' is not added to the list, the match function isn't called on Linux, so status() would miss any normal files that were also in a named directory. The commit then proceeds without those normal files, or says "nothing changed" if there were no changed largefiles in the directory. This is not filesystem specific, as VFAT on Linux had the same behavior as when run on ext4. It is also not an issue with lfilesrepo.status(), since that only calls the overridden implementation when paths are passed to commit. I dont have access to an OS X machine ATM to test there. Maybe there's a better way to do this. But since the standin directory for the first largefile was previously being added, and that caused the same walk in status(), there's no preformance change to this. There is no danger of erroneously committing files in '.', because the original match function is called, and if it fails, the lfutil.updatestandinsbymatch() tweaked matcher only indicates a match if the file is in the list of standins- and '.' never is. The added tests confirm this.
Sun, 18 Jan 2015 16:38:56 -0500 test-tools: update for platforms without symlink support after 5b20e4c32117 stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 16:38:56 -0500] rev 23922
test-tools: update for platforms without symlink support after 5b20e4c32117 The change was triggered by removing the 'baz' hardlink.
Sun, 18 Jan 2015 16:33:41 -0500 tests: add "(glob)" to output in test-histedit-commute.t for Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Jan 2015 16:33:41 -0500] rev 23921
tests: add "(glob)" to output in test-histedit-commute.t for Windows This goes with the changes in 3831e9b3750a.
Sat, 17 Jan 2015 18:29:30 -0800 Added signature for changeset db8e3f7948b1 stable
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:29:30 -0800] rev 23920
Added signature for changeset db8e3f7948b1
Sat, 17 Jan 2015 18:29:05 -0800 Added tag 3.3-rc for changeset db8e3f7948b1 stable
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:29:05 -0800] rev 23919
Added tag 3.3-rc for changeset db8e3f7948b1
Sat, 17 Jan 2015 18:28:30 -0800 merge default into stable for 3.3 feature freeze stable 3.3-rc
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:28:30 -0800] rev 23918
merge default into stable for 3.3 feature freeze
Sat, 17 Jan 2015 22:01:14 -0200 messages: quote "hg help" hints consistently
Wagner Bruna <wbruna@yahoo.com> [Sat, 17 Jan 2015 22:01:14 -0200] rev 23917
messages: quote "hg help" hints consistently
Sat, 17 Jan 2015 18:08:47 -0800 bundle2: fix parttype enforcement
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 18:08:47 -0800] rev 23916
bundle2: fix parttype enforcement As spotted by Malte Helmert.
Sat, 17 Jan 2015 17:59:30 -0800 test-tools: another vfat fix
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 17:59:30 -0800] rev 23915
test-tools: another vfat fix
Sat, 17 Jan 2015 15:54:03 -0800 test-tools: check for unix permissions for hardlinking
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 15:54:03 -0800] rev 23914
test-tools: check for unix permissions for hardlinking
Sat, 17 Jan 2015 15:28:56 -0800 tests: more fixes for f
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 15:28:56 -0800] rev 23913
tests: more fixes for f
Sat, 17 Jan 2015 13:53:56 -0800 tests: teach f not to report symlink mode bits
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:53:56 -0800] rev 23912
tests: teach f not to report symlink mode bits They're not meaningful or portable
Sat, 17 Jan 2015 13:53:16 -0800 tests: teach f not to report directory size
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:53:16 -0800] rev 23911
tests: teach f not to report directory size It's not meaningful or portable
Sat, 17 Jan 2015 13:44:43 -0800 test-histedit-commute: call helper script with sh
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:44:43 -0800] rev 23910
test-histedit-commute: call helper script with sh Buildbot pointed out that this test wasn't passing on Linux+vfat because there's no chmod for shell scripts.
Sat, 17 Jan 2015 13:38:17 -0800 test-tools: fix portability issues
Matt Mackall <mpm@selenic.com> [Sat, 17 Jan 2015 13:38:17 -0800] rev 23909
test-tools: fix portability issues
Sat, 17 Jan 2015 13:13:16 -0800 progress: add a lock to prepare for introducing a thread
Solomon Matthews <smat@fb.com> [Sat, 17 Jan 2015 13:13:16 -0800] rev 23908
progress: add a lock to prepare for introducing a thread
Sat, 17 Jan 2015 13:10:37 -0800 progress: move update check into helper method
Solomon Matthews <smat@fb.com> [Sat, 17 Jan 2015 13:10:37 -0800] rev 23907
progress: move update check into helper method
(0) -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 +1000 +3000 +10000 tip