Fri, 11 Mar 2016 22:30:43 +0800 patchbomb: specify unit for ui.progress when sending emails
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:30:43 +0800] rev 28474
patchbomb: specify unit for ui.progress when sending emails
Fri, 11 Mar 2016 22:28:27 +0800 streamclone: specify unit for ui.progress when handling data
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:28:27 +0800] rev 28473
streamclone: specify unit for ui.progress when handling data
Fri, 11 Mar 2016 22:30:29 +0800 churn: specify unit for ui.progress when analyzing revisions
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:30:29 +0800] rev 28472
churn: specify unit for ui.progress when analyzing revisions
Fri, 11 Mar 2016 22:30:04 +0800 convert: specify unit for ui.progress when scanning paths
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:30:04 +0800] rev 28471
convert: specify unit for ui.progress when scanning paths
Fri, 11 Mar 2016 22:29:51 +0800 convert: specify unit for ui.progress when operating on files
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:29:51 +0800] rev 28470
convert: specify unit for ui.progress when operating on files
Fri, 11 Mar 2016 05:47:39 +0000 tests: stabilize svn output
timeless <timeless@mozdev.org> [Fri, 11 Mar 2016 05:47:39 +0000] rev 28469
tests: stabilize svn output With 1.9.3 extra bits were appearing...
Fri, 11 Mar 2016 22:29:20 +0800 similar: specify unit for ui.progress when operating on files
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:29:20 +0800] rev 28468
similar: specify unit for ui.progress when operating on files
Fri, 11 Mar 2016 20:18:41 +0800 verify: specify unit for ui.progress when checking files
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:18:41 +0800] rev 28467
verify: specify unit for ui.progress when checking files
Fri, 11 Mar 2016 20:44:40 +0800 repair: specify unit for ui.progress in rebuildfncache()
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:44:40 +0800] rev 28466
repair: specify unit for ui.progress in rebuildfncache()
Fri, 11 Mar 2016 20:39:29 +0800 repair: use 'rebuilding' progress topic in rebuildfncache()
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:39:29 +0800] rev 28465
repair: use 'rebuilding' progress topic in rebuildfncache()
Fri, 11 Mar 2016 22:26:06 +0800 largefiles: use revisions as a ui.progress unit
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:26:06 +0800] rev 28464
largefiles: use revisions as a ui.progress unit Using plural form is consistent with other progress units, and "1 out of 5 revisions" sounds more correct. Also, tests don't show this, but if you have 'speed' item in progress.format config, it shows e.g. '100 revisions/sec', which also seems better.
Fri, 11 Mar 2016 22:21:43 +0800 largefiles: specify unit for ui.progress when operating on files
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 22:21:43 +0800] rev 28463
largefiles: specify unit for ui.progress when operating on files Also make it available for translation. It could already be translated, because it's used as a unit in archival.py and subrepo.py, for example.
Wed, 09 Mar 2016 23:59:26 +0900 templater: make label() just fail if ui object isn't available
Yuya Nishihara <yuya@tcha.org> [Wed, 09 Mar 2016 23:59:26 +0900] rev 28462
templater: make label() just fail if ui object isn't available Silent failure hides bugs and makes it harder to track down the issue. It's worse than raising exception. In future patches, I plan to sort out template functions that require 'ui', 'ctx', 'fctx', etc. so that incompatible functions are excluded and the doc can say in which context these functions are usable. @templatefunc('label', requires=('ui',)) def label(context, mapping, args): ...
Fri, 11 Mar 2016 21:55:44 +0900 convert: fix "stdlib import follows local import" problem in transport
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 21:55:44 +0900] rev 28461
convert: fix "stdlib import follows local import" problem in transport Before this patch, import-checker reports error below for importing subversion python binding libraries. stdlib import "svn.*" follows local import: mercurial
Fri, 11 Mar 2016 21:55:44 +0900 convert: fix relative import of stdlib module in subversion
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 21:55:44 +0900] rev 28460
convert: fix relative import of stdlib module in subversion Before this patch, import-checker reports "relative import of stdlib module" error for importing Pool and SubversionException from svn.core in subversion.py. To fix this relative import of stdlib module, this patch adds prefix 'svn.core.' to Pool and SubversionException in source. These 'svn.core.' relative accessing shouldn't cause performance impact, because there are much more code paths accessing to 'svn.core.' relative properties. BTW, in transport.py, this error is avoided by assignment below. SubversionException = svn.core.SubversionException But this can't be used in subversion.py case, because: - such assignment in indented code block causes "don't use camelcase in identifiers" error of check-code.py - but it should be placed in indented block, because svn is None at failure of importing subversion python binding libraries (= examination of 'svn' is needed)
Fri, 11 Mar 2016 21:55:44 +0900 convert: make subversion import transport locally
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 21:55:44 +0900] rev 28459
convert: make subversion import transport locally Introducing "absolute_import" feature in previous patch caused failure of importing local module "transport".
Fri, 11 Mar 2016 08:27:11 +0000 keyword: compact writing of temporary kwdemo hgrc
Christian Ebert <blacktrash@gmx.net> [Fri, 11 Mar 2016 08:27:11 +0000] rev 28458
keyword: compact writing of temporary kwdemo hgrc
Thu, 10 Mar 2016 23:46:19 +0800 dockerdeb: add Ubuntu Trusty
Anton Shestakov <av6@dwimlabs.net> [Thu, 10 Mar 2016 23:46:19 +0800] rev 28457
dockerdeb: add Ubuntu Trusty One problem reported by lintian is "bad-distribution-in-changes-file unstable" in changelog, but the current changelog for the official package in Ubuntu also uses that distribution name (unstable), because they import from Debian. This certainly doesn't stop the build process.
Thu, 10 Mar 2016 17:31:38 -0600 pushoperation: fix language issues in docstring
Nathan Goldbaum <ngoldbau@illinois.edu> [Thu, 10 Mar 2016 17:31:38 -0600] rev 28456
pushoperation: fix language issues in docstring
Thu, 10 Mar 2016 00:19:55 +0000 chg: do not write pidfile
Jun Wu <quark@fb.com> [Thu, 10 Mar 2016 00:19:55 +0000] rev 28455
chg: do not write pidfile Current pidfile logic will only keep the pid of the newest server, which is not very useful if we want to kill all servers, and will become outdated if the server auto exits after being idle for too long. Besides, the server-side pidfile writing logic runs before chgserver gets confighash so it's not trivial to append confighash to pidfile basename like we did for socket file. This patch removes --pidfile from the command starting chgserver and switches to an alternative way (unlink socket file) to stop the server.
Thu, 10 Mar 2016 00:12:33 +0000 chg: remove manual reload logic
Jun Wu <quark@fb.com> [Thu, 10 Mar 2016 00:12:33 +0000] rev 28454
chg: remove manual reload logic chgserver now validates and reloads configs automatically. Manually reloading is no longer necessary. Besides, we are deprecating pid files since the server will periodically check its ownership of the socket file and exit if it does not own the socket file any longer, which works more reliable than a pid file. This patch removes the SIGHUP reload logic from both chg server and client.
Wed, 09 Mar 2016 01:20:57 +0000 chg: use --daemon-postexec chdir:/ instead of --cwd /
Jun Wu <quark@fb.com> [Wed, 09 Mar 2016 01:20:57 +0000] rev 28453
chg: use --daemon-postexec chdir:/ instead of --cwd / The chgserver is designed to load repo config from current directory. "--cwd /" will prevent chgserver from loading repo config and generate a wrong confighash, which will result in a redirect loop. This patch removes "--cwd /" and uses "--daemon-postexec chdir:/" instead.
Wed, 09 Mar 2016 01:17:02 +0000 serve: add chdir command for --daemon-postexec
Jun Wu <quark@fb.com> [Wed, 09 Mar 2016 01:17:02 +0000] rev 28452
serve: add chdir command for --daemon-postexec For chgserver, it probably needs a chdir to /. This patch adds chdir command support for --daemon-postexec so chg client can make use of it.
Wed, 09 Mar 2016 02:07:40 +0000 serve: accept multiple values for --daemon-postexec
Jun Wu <quark@fb.com> [Wed, 09 Mar 2016 02:07:40 +0000] rev 28451
serve: accept multiple values for --daemon-postexec The next patch will add another postexec command: chdir, which can be used together with unlink. This patch changes the option type of --daemon-postexec from string to list to accept multiple commands. The error message of invalid --daemon-postexec value is also changed to include the actual invalid value.
Sat, 27 Feb 2016 12:56:26 +0100 hgext: officially turn 'hgext' into a namespace package
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 27 Feb 2016 12:56:26 +0100] rev 28450
hgext: officially turn 'hgext' into a namespace package Actually since Python 2.3, there is some way to turn top level package into "namespace package" so that multiple subpackage installed in different part of the path can still be imported transparently. This feature was previously thought (at least by myself) to be only provided by some setuptool black magic. Turning hgext into such namespace package allows third extensions to install themselves inside the "hgext" namespace package to avoid polluting the global python module namespace. They will now be able to do so without making it a pain to use a Mercurial "installed" in a different way/location than these extensions. The only constrains is that the extension ship a 'hgext/__init__.py' containing the same call to 'pkgutil.extend_path' and nothing else. This seems realistic. The main question that remains is: should we introduce a dedicated namespace for third party extension (hgext3rd?) to make a clearer distinction between what is officially supported and what is not? If so, this will be introduced in a follow up patch.
Fri, 11 Mar 2016 15:24:27 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 11 Mar 2016 15:24:27 -0600] rev 28449
merge with stable
Fri, 11 Mar 2016 04:14:54 +0900 fileset: replace predicate by filesetpredicate of registrar (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 04:14:54 +0900] rev 28448
fileset: replace predicate by filesetpredicate of registrar (API) To make all built-in predicates be known to hggettext, loading built-in predicates by loadpredicate() should be placed before fixing i18nfunctions but after all of predicate decorating.
Fri, 11 Mar 2016 04:14:54 +0900 registrar: add filesetpredicate to mark a function as fileset predicate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 04:14:54 +0900] rev 28447
registrar: add filesetpredicate to mark a function as fileset predicate filesetpredicate is used to replace fileset.predicate in subsequent patch. This patch also adds loadpredicate() to fileset, because this combination helps to figure out how the name of "status caller" (or "existing caller") predicate is put into _statuscallers (or _existingcallers). Listing up loadpredicate() in dispatch.extraloaders causes implicit loading fileset predicate functions at loading (3rd party) extension.
Fri, 11 Mar 2016 04:14:54 +0900 registrar: remove useless base classes (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 04:14:54 +0900] rev 28446
registrar: remove useless base classes (API) Previous patches make these classes useless by removing classes derived from them.
Fri, 11 Mar 2016 04:14:54 +0900 revset: remove useless extpredicate class (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 11 Mar 2016 04:14:54 +0900] rev 28445
revset: remove useless extpredicate class (API) Previous patch makes this classes useless by replacing it with revsetpredicate of registrar. BTW, extpredicate itself has already been broken by that patch, because revsetpredicate of registrar doesn't have compatibility with original predicate (derived from funcregistrar of registrar), in fact.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip