Sun, 06 Jul 2014 02:56:41 +0900 progress: use 'encoding.trim' to trim output line correctly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21859
progress: use 'encoding.trim' to trim output line correctly Before this patch, 'progress' extension trims output line by directly slicing byte sequence, but it may split at intermediate multi-byte sequence. This patch uses 'encoding.trim' to trim output line correctly, even if it contains multi-byte characters. "rm -f loop.pyc" before changing "loop.py" in "test-progress.t" ensures that re-compilation of "loop.py", even if "loop.py" and "loop.pyc" have same timestamp in seconds.
Sun, 06 Jul 2014 02:56:41 +0900 histedit: use 'util.ellipsis' to trim description of each changesets
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21858
histedit: use 'util.ellipsis' to trim description of each changesets Before this patch, trimming description of each changesets in histedit may split at intermediate multi-byte sequence. This patch uses 'util.ellipsis' to trim description of each changesets instead of directly slicing byte sequence. Even though 'util.ellipsis' adds '...' as ellipsis when specified string is trimmed (= this changes result of trimming), this patch uses it, because: - it can be used without any additional 'import', and - ellipsis seems to be better than just trimming, for usability
Sun, 06 Jul 2014 02:56:41 +0900 util: replace 'ellipsis' implementation by 'encoding.trim'
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21857
util: replace 'ellipsis' implementation by 'encoding.trim' Before this patch, 'util.ellipsis' tried to avoid splitting at intermediate multi-byte sequence, but its implementation was incorrect. Internal function '_ellipsis' trims specified unicode sequence not at most maxlength 'columns in display', but at most maxlength number of 'unicode characters'. def _ellipsis(text, maxlength): if len(text) <= maxlength: return text, False else: return "%s..." % (text[:maxlength - 3]), True In many encodings, number of unicode characters can be different from columns in display. This patch replaces 'ellipsis' implementation by 'encoding.trim', which can trim string at most maxlength columns in display correctly, even though specified string contains multi-byte characters. '_ellipsis' is removed in this patch, because it is referred only from 'ellipsis'.
Sun, 06 Jul 2014 02:56:41 +0900 encoding: add 'trim' to trim multi-byte characters at most specified columns
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21856
encoding: add 'trim' to trim multi-byte characters at most specified columns Newly added 'trim' is used to trim multi-byte characters at most specified columns correctly: directly slicing byte sequence should be replaced with 'encoding.trim', because the former may split at intermediate multi-byte sequence. Slicing unicode sequence ('uslice') and concatenation with ellipsis ('concat') are defined as function, to make enhancement in subsequent patch easier.
Thu, 03 Jul 2014 10:48:37 +0100 bugzilla: stop trying to cache setup across hook invocation stable
Jim Hague <jim.hague@acm.org> [Thu, 03 Jul 2014 10:48:37 +0100] rev 21855
bugzilla: stop trying to cache setup across hook invocation In the context of standalone Hg receiving a set of incoming changes, it makes sense for the Bugzilla module to cache basic setup to avoid reconnecting to Bugzilla for each change. After processing the changes, Hg will exit and so the connection is short-lived. But this doesn't work too well when used from a long-lived environment such as hgweb or Kallithea where, for example, the connection can time out. So take the simple approach, abandon the cache and do the basic setup on each call. This fixes current problems with Kallithea.
Fri, 11 Jul 2014 18:04:51 -0500 strip: drop -b/--backup option (BC)
Matt Mackall <mpm@selenic.com> [Fri, 11 Jul 2014 18:04:51 -0500] rev 21854
strip: drop -b/--backup option (BC) This option had very limited utility and counterintuitive behavior and collided unfortunately with the much later -B option. Normally we would no-op such a feature so as to avoid annoying existing scripts. However, we have to weigh that against the silent misbehavior that results when users mistakenly intended to use -B: because -b takes no arg, the bookmark gets interpreted as a normal revision, and gets stripped without removing the associated bookmark, while also not backing up the revision in question. A no-op behavior or warning would only remove the latter half of the misadventure. The only users I can find of this feature were using it in error and have since stopped. The few (if any) remaining users of this feature would be better served by --no-backup.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip