Wed, 27 Sep 2017 19:11:28 +0900 py3: manually escape control character to be embedded in win filename error
Yuya Nishihara <yuya@tcha.org> [Wed, 27 Sep 2017 19:11:28 +0900] rev 34360
py3: manually escape control character to be embedded in win filename error
Wed, 27 Sep 2017 19:08:23 +0900 py3: replace str(None) with literal in convcmd.py
Yuya Nishihara <yuya@tcha.org> [Wed, 27 Sep 2017 19:08:23 +0900] rev 34359
py3: replace str(None) with literal in convcmd.py
Wed, 27 Sep 2017 19:04:32 +0900 py3: remove use of str() in hgwebdir
Yuya Nishihara <yuya@tcha.org> [Wed, 27 Sep 2017 19:04:32 +0900] rev 34358
py3: remove use of str() in hgwebdir '%d' can't be used here since port may be either integer or byte string.
Wed, 27 Sep 2017 18:07:48 -0700 config: use copy-on-write to improve copy performance
Jun Wu <quark@fb.com> [Wed, 27 Sep 2017 18:07:48 -0700] rev 34357
config: use copy-on-write to improve copy performance Previously, chg's `verify` call could take 30+ms loading and checking new config files. With one socket redirection, that adds up to around 70ms, which is a lot for fast commands (ex. `bookmark --hidden`). When investigating closer, A lot of time was spent on actually spent on ui copying, which is mainly about `config.config` and `dict` copying. This patch makes that 20x faster by adopting copy-on-write. The copy-on-write is performed at config section level. Before: In [1]: %timeit ui.copy() 100 loops, best of 3: 2.32 ms per loop After: In [1]: %timeit ui.copy() 10000 loops, best of 3: 128 us per loop 2ms may look not that bad, but it adds up pretty quickly with multiple calls. A typical chg run may call it 4 times, which is about 10ms. Differential Revision: https://phab.mercurial-scm.org/D808
Sun, 01 Oct 2017 05:28:54 -0400 Added signature for changeset 2f427b57bf90 stable
Augie Fackler <raf@durin42.com> [Sun, 01 Oct 2017 05:28:54 -0400] rev 34356
Added signature for changeset 2f427b57bf90
Sun, 01 Oct 2017 05:28:49 -0400 Added tag 4.3.3 for changeset 2f427b57bf90 stable
Augie Fackler <raf@durin42.com> [Sun, 01 Oct 2017 05:28:49 -0400] rev 34355
Added tag 4.3.3 for changeset 2f427b57bf90
Mon, 18 Sep 2017 10:54:00 -0700 rebase: move bookmarks with --keep (issue5682) stable 4.3.3
Jun Wu <quark@fb.com> [Mon, 18 Sep 2017 10:54:00 -0700] rev 34354
rebase: move bookmarks with --keep (issue5682) This is a regression caused by 3b7cb3d17137. We have documented the behavior in rebase help: Rebase will destroy original commits unless you use "--keep". It will also move your bookmarks (even if you do). So let's restore the old behavior. It is done by changing `scmutil.cleanupnodes` to accept more information so a node could have different "movement destination" from "successors". It also helps simplifying the callsite as a side effect - the special bookmark movement logic in rebase is removed. Differential Revision: https://phab.mercurial-scm.org/D727
Wed, 20 Sep 2017 09:32:26 -0700 cleanupnodes: rename "mapping" to "replacements" stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Sep 2017 09:32:26 -0700] rev 34353
cleanupnodes: rename "mapping" to "replacements" The next patch will pass in overrides for bookmark moves, which is a mapping itself, so let's rename "mapping" to "replacements" to distinguish them better. Differential Revision: https://phab.mercurial-scm.org/D749
Wed, 20 Sep 2017 09:10:43 -0700 cleanupnodes: separate out bookmark destination calculation from actual update stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 20 Sep 2017 09:10:43 -0700] rev 34352
cleanupnodes: separate out bookmark destination calculation from actual update We will soon want to pass in overrides for bookmark movements and this will make that patch simpler. I also think this makes the code easier to follow regardless of the later patch. Differential Revision: https://phab.mercurial-scm.org/D748
Wed, 20 Sep 2017 09:55:52 -0700 ui: check for progress singleton when clearing progress bar (issue5684) stable
Mark Thomas <mbthomas@fb.com> [Wed, 20 Sep 2017 09:55:52 -0700] rev 34351
ui: check for progress singleton when clearing progress bar (issue5684) A combination of wrapping `ui` and progress bars interrupted by exceptions can lead to the progress bar not being cleared when the exception error is printed. This results in corrupted-looking output like this: ``` updating [===============================> ] 1/2u nresolved conflicts (see hg resolve, then hg rebase --continue) ``` This is because in `ui._progclear`, we only check the local reference to the progress bar, not whether or not there is an instance of the singleton. When a progress bar is interrupted by an exception, the exception printing in `scmutil.callcatch` uses the original instance of the `ui` object, not the wrapped copy that has `_progbar` set. When consider whether or not to clear the progress bar, check for the existence of the singleton, rather than just whether or not we have a local reference to it. Differential Revision: https://phab.mercurial-scm.org/D743
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip