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...
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
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:18:41 +0800] rev 28467
verify: specify unit for ui.progress when checking files
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:44:40 +0800] rev 28466
repair: specify unit for ui.progress in rebuildfncache()
Anton Shestakov <av6@dwimlabs.net> [Fri, 11 Mar 2016 20:39:29 +0800] rev 28465
repair: use 'rebuilding' progress topic in rebuildfncache()
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.
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.
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):
...
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
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)