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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip