Sun, 15 Feb 2015 17:29:10 -0500 subrepo: return only the manifest keys from hgsubrepo.files()
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Feb 2015 17:29:10 -0500] rev 24173
subrepo: return only the manifest keys from hgsubrepo.files() This is in line with the other subrepo classes (i.e. only the filenames are returned). Archive iterates over the manifest keys, and since subrepo archive() uses this method, it does too now. This will allow largefiles to override its manifest keys to present the largefiles instead of the standins. Once in place, we shouldn't need the copy/paste overrides of archive and subrepo archive in largefiles, that don't quite behave like the core methods they are overriding.
Sun, 15 Feb 2015 17:21:48 -0500 archive: change the default prefix to '' from None
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Feb 2015 17:21:48 -0500] rev 24172
archive: change the default prefix to '' from None All current callers supply some sort of prefix, so the issue was hidden. But if no parameter was specified, a crash occurred in the write() closure when concatenating 'prefix' and 'name'.
Wed, 25 Feb 2015 11:39:14 -0800 debugsetparent: document one common caveat specifically
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Feb 2015 11:39:14 -0800] rev 24171
debugsetparent: document one common caveat specifically After calling debugsetparent, it's quite common that status is incorrect. The command's help text already says that it should be used with care, but let's describe this caveat explicitly since it's probably the most common one.
Fri, 20 Feb 2015 13:55:01 -0800 repair: setup hookargs when processing bundle2s
Eric Sumner <ericsumner@fb.com> [Fri, 20 Feb 2015 13:55:01 -0800] rev 24170
repair: setup hookargs when processing bundle2s addchangegroup() modifies its behavior based on the transaction source. This is incorrect for bundle2 repair files, causing rebases to abort when this option is enabled. This diff specifies the source type in the way recommended by comments in bundle2.py and adds a test to ensure that rebases with the experimental option work successfully.
Mon, 02 Mar 2015 19:01:00 +0000 amend: check for directory renames for both merge parents (issue4516) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 02 Mar 2015 19:01:00 +0000] rev 24169
amend: check for directory renames for both merge parents (issue4516) Before this change, amending a merge would lose the rename information for file adding in the second parents and implicitly renamed into a new directory. In case of the merge, we also look for directory rename data from the second parent. This seems to fix the bug and does not show other issues from the test suite.
Mon, 02 Mar 2015 10:55:19 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 10:55:19 -0600] rev 24168
merge with stable
Mon, 02 Mar 2015 23:37:55 +0900 largefiles: avoid infinite recursive call of openlfdirstate in overriderevert
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Mar 2015 23:37:55 +0900] rev 24167
largefiles: avoid infinite recursive call of openlfdirstate in overriderevert When there isn't lfdirstate file in cases below, "openlfdirstate()" call "scmutil.match()" indirectly to build lfdirstate up. - subrepos disabling largefiles locally - lfdirstate file is missed accidentally This causes infinite recursive call of "openlfdirstate()" in "overriderevert()" (introduced by 79c2c29c71ae), because "openlfdirstate()" is invoked from the function overriding "scmutil.match()" itself. To avoid infinite recursive call of "openlfdirstate()" in "overriderevert()" in such cases, this patch passes "create=False" argument to "openlfdirstate()". "create=False" forcibly makes "openlfdirstate()" avoid code path to build lfdirstate up.
Mon, 02 Mar 2015 10:29:45 -0600 Added signature for changeset 07a92bbd02e5 stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 10:29:45 -0600] rev 24166
Added signature for changeset 07a92bbd02e5
Mon, 02 Mar 2015 10:29:41 -0600 Added tag 3.3.2 for changeset 07a92bbd02e5 stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 10:29:41 -0600] rev 24165
Added tag 3.3.2 for changeset 07a92bbd02e5
Mon, 02 Mar 2015 10:31:22 -0500 transaction: really disable hardlink backups (issue4546) stable 3.3.2
Matt Harbison <matt_harbison@yahoo.com> [Mon, 02 Mar 2015 10:31:22 -0500] rev 24164
transaction: really disable hardlink backups (issue4546)
Mon, 02 Mar 2015 01:20:14 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 01:20:14 -0600] rev 24163
merge with stable
Sat, 28 Feb 2015 01:12:54 -0500 test-obsolete: use 'log -T {node}' instead of 'id --debug -i' to lookup hash
Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Feb 2015 01:12:54 -0500] rev 24162
test-obsolete: use 'log -T {node}' instead of 'id --debug -i' to lookup hash I ran into a case when adding a test where there were cryptic hg command line errors. I eventually traced it back to 'hg id' printing debug messages before the hash: invalid branchheads cache (served): tip differs <hash> This method should eliminate any other output except the node.
Mon, 02 Mar 2015 01:06:31 -0600 Added signature for changeset 5b4ed033390b stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 01:06:31 -0600] rev 24161
Added signature for changeset 5b4ed033390b
Mon, 02 Mar 2015 01:06:27 -0600 Added tag 3.3.1 for changeset 5b4ed033390b stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 01:06:27 -0600] rev 24160
Added tag 3.3.1 for changeset 5b4ed033390b
Fri, 06 Feb 2015 02:52:10 +0100 revisionbranchcache: fall back to slow path if starting readonly (issue4531) stable 3.3.1
Mads Kiilerich <madski@unity3d.com> [Fri, 06 Feb 2015 02:52:10 +0100] rev 24159
revisionbranchcache: fall back to slow path if starting readonly (issue4531) Transitioning to Mercurial versions with revision branch cache could be slow as long as all operations were readonly (revset queries) and the cache would be populated but not written back. Instead, fall back to using the consistently slow path when readonly and the cache doesn't exist yet. That avoids the overhead of populating the cache without writing it back. If not readonly, it will still populate all missing entries initially. That avoids repeated writing of the cache file with small updates, and it also makes sure a fully populated cache available for the readonly operations.
Thu, 26 Feb 2015 06:03:39 +0900 largefiles: access to specific fields only if largefiles enabled (issue4547) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 26 Feb 2015 06:03:39 +0900] rev 24158
largefiles: access to specific fields only if largefiles enabled (issue4547) Even if largefiles extension is enabled in a repository, "repo" object, which isn't "largefiles.reposetup()"-ed, is passed to overridden functions in the cases below unexpectedly, because extensions are enabled for each repositories strictly. (1) clone without -U: (2) pull with -U: (3) pull with --rebase: combination of "enabled@src", "disabled@dst" and "not-required@src" cause this situation. largefiles requirement @src @dst @src result -------- -------- --------------- -------------------- enabled disabled not-required aborted unexpectedly required requirement error (intentional) -------- -------- --------------- -------------------- enabled enabled * success -------- -------- --------------- -------------------- disabled enabled * success (only for "pull") -------- -------- --------------- -------------------- disabled disabled not-required success required requirement error (intentional) -------- -------- --------------- -------------------- (4) update/revert with a subrepo disabling largefiles In these cases, overridden functions cause accessing to largefiles specific fields of not "largefiles.reposetup()"-ed "repo" object, and execution is aborted. - (1), (2), (4) cause accessing to "_lfstatuswriters" in "getstatuswriter()" invoked via "updatelfiles()" - (3) causes accessing to "_lfcommithooks" in "overriderebase()" For safe accessing to these fields, this patch examines whether passed "repo" object is "largefiles.reposetup()"-ed or not before accessing to them. This patch chooses examining existence of newly introduced "_largefilesenabled" instead of "_lfcommithooks" and "_lfstatuswriters" directly, because the former is better name for the generic "largefiles is enabled in this repo" mark than the latter. In the future, all other overridden functions should avoid largefiles specific processing for efficiency, and "_largefilesenabled" is better also for such purpose. BTW, "lfstatus" can't be used for such purpose, because some code paths set it forcibly regardless of existence of it in specified "repo" object.
Wed, 18 Feb 2015 22:17:35 +0900 templatekw: fix {join(bookmarks, sep)} to always show associated bookmarks stable
Yuya Nishihara <yuya@tcha.org> [Wed, 18 Feb 2015 22:17:35 +0900] rev 24157
templatekw: fix {join(bookmarks, sep)} to always show associated bookmarks The default joinfmt, "x.values()[0]", can't be used here because it picks either 'bookmark' or 'current' randomly. I got wrong result with PYTHONHASHSEED=1 on my amd64 machine.
Wed, 18 Feb 2015 22:10:17 +0900 templatekw: inline showlist() into showbookmarks() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 18 Feb 2015 22:10:17 +0900] rev 24156
templatekw: inline showlist() into showbookmarks() showlist() is the helper to build _hybrid object from a trivial list. It can't be applied if each value has more than one items, 'bookmark' and 'current' in this case. This change is necessary to fix random failure of "{join(bookmarks, sep)}".
Mon, 02 Mar 2015 00:12:29 -0600 transaction: disable hardlink backups (issue4546) stable
Matt Mackall <mpm@selenic.com> [Mon, 02 Mar 2015 00:12:29 -0600] rev 24155
transaction: disable hardlink backups (issue4546) Causing troubles, simplest fix.
Sun, 01 Mar 2015 23:20:02 -0600 repoview: invalidate cached changelog if _delayed changes (issue4549) stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Mar 2015 23:20:02 -0600] rev 24154
repoview: invalidate cached changelog if _delayed changes (issue4549) Starting with 2d54aa5397cd, when a clone reached the checkout stage, the cached changelog in the filtered view was still seeing the _delayed flag, even though the changelog had already been finalized.
Thu, 26 Feb 2015 10:23:04 -0800 test: make test-extdiff resilient to */gnubin/echo stable
Sean Farley <sean.michael.farley@gmail.com> [Thu, 26 Feb 2015 10:23:04 -0800] rev 24153
test: make test-extdiff resilient to */gnubin/echo My Mac test machine has 'echo' in '/opt/local/libexec/gnubin/echo' since, well, GNU is not BSD. Also, I feel it need to be said about using regexes: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Thu, 26 Feb 2015 23:30:33 +0900 dispatch: work around UnicodeDecodeError caused by SSLError of Python 2.7.9 stable
Yuya Nishihara <yuya@tcha.org> [Thu, 26 Feb 2015 23:30:33 +0900] rev 24152
dispatch: work around UnicodeDecodeError caused by SSLError of Python 2.7.9 SSLError of Python 2.7.9 may keep error message in unicode. It will be wrapped by URLError(reason) at KeepAliveHandler.do_open, so inst.reason can be a unicode. https://hg.python.org/cpython/file/v2.7.9/Modules/_ssl.c#l329
Thu, 05 Feb 2015 14:45:49 +0900 revset: mask specific names for named() predicate stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 05 Feb 2015 14:45:49 +0900] rev 24151
revset: mask specific names for named() predicate Before this patch, revset predicate "tag()" and "named('tags')" differ from each other, because the former doesn't include "tip" but the latter does. For equivalence, "named('tags')" shouldn't include the revision corresponded to "tip". But just removing "tip" from the "tags" namespace causes breaking backward compatibility, even though "tip" itself is planned to be eliminated, as mentioned below. http://selenic.com/pipermail/mercurial-devel/2015-February/066157.html To mask specific names ("tip" in this case) for "named()" predicate, this patch introduces "deprecated" into "namespaces", and makes "named()" predicate examine whether each names are masked by the namespace, to which they belong. "named()" will really work correctly after 3.3.1 (see 873eb5db89c8 for detail), and fixing this on STABLE before 3.3.1 can prevent initial users of "named()" from expecting "named('tags')" to include "tip". It is reason why this patch is posted for STABLE, even though problem itself isn't so serious. This may have to be flagged as "(BC)", if applied on DEFAULT.
Sun, 01 Mar 2015 00:18:43 -0300 i18n-pt_BR: synchronized with 756c5c8331b0 stable
Wagner Bruna <wbruna@yahoo.com> [Sun, 01 Mar 2015 00:18:43 -0300] rev 24150
i18n-pt_BR: synchronized with 756c5c8331b0
Sun, 01 Mar 2015 01:28:05 +0900 i18n-ja: synchronized with 756c5c8331b0 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Mar 2015 01:28:05 +0900] rev 24149
i18n-ja: synchronized with 756c5c8331b0
Fri, 27 Feb 2015 17:46:03 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 27 Feb 2015 17:46:03 -0600] rev 24148
merge with stable
Tue, 24 Feb 2015 09:08:54 -0800 manifest: rename 'mf', 'map', and 'mapping' to 'm'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 24 Feb 2015 09:08:54 -0800] rev 24147
manifest: rename 'mf', 'map', and 'mapping' to 'm' We mostly call manifest variables 'm', so let's use that in manifest.py too. This makes it clearer that the variables do, in fact, contain manifestsdict instances and never a plain dict.
Mon, 23 Feb 2015 13:41:02 -0800 manifest: make copy logic local to copy()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Feb 2015 13:41:02 -0800] rev 24146
manifest: make copy logic local to copy() The optional arguments to the manfifestdict constructor are only used by copy(), so assign the fields from that method instead so it's clear that the arguments are not used for anything else.
(0) -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip