Mon, 10 Oct 2016 12:06:58 +0200 cmdutil: add support for evolution "troubles" display in changeset_printer
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Oct 2016 12:06:58 +0200] rev 30695
cmdutil: add support for evolution "troubles" display in changeset_printer Add a "trouble" line in changeset header along with a couple of labels on "log.changeset" line to indicate whether a changeset is troubled or not and which kind trouble occurs.
Tue, 03 Jan 2017 10:56:41 +0100 cmdutil: extract a _changesetlabels function out of changeset_printer._show()
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 03 Jan 2017 10:56:41 +0100] rev 30694
cmdutil: extract a _changesetlabels function out of changeset_printer._show() There is a common logic in changeset_printer and in the summary command for labelling a changeset. This prepares extension of changeset's labels with evolution "troubles" information that would show up in both log and summary outputs. Ultimately, both would use this function.
Mon, 02 Jan 2017 14:57:14 +0000 chg: add procutil.h
Jun Wu <quark@fb.com> [Mon, 02 Jan 2017 14:57:14 +0000] rev 30693
chg: add procutil.h This patch adds a formal header procutil.h for procutil.c, and changes Makefile to build procutil.c independently.
Mon, 02 Jan 2017 14:43:37 +0000 chg: let procutil maintain its own pagerpid
Jun Wu <quark@fb.com> [Mon, 02 Jan 2017 14:43:37 +0000] rev 30692
chg: let procutil maintain its own pagerpid Previously, chg.c maintains the pagerpid. Let's move it to procutil.c. Note: chg.c still have a pagerpid to decide whether to call attachio or not. In the future, attachio may be moved from hgc_open to hgc_runcommand, and hgc_runcommand handles both pager and attachio so we don't need to run attachio twice. And chg.c will be free of pagerpid.
Mon, 02 Jan 2017 14:10:32 +0000 chg: decouple hgclient from setuppager
Jun Wu <quark@fb.com> [Mon, 02 Jan 2017 14:10:32 +0000] rev 30691
chg: decouple hgclient from setuppager procutil should not depend on hgclient. This patch makes the pager handling part independent from hgclient.
Mon, 02 Jan 2017 14:04:35 +0000 chg: decouple hgclient from setupsignalhandler
Jun Wu <quark@fb.com> [Mon, 02 Jan 2017 14:04:35 +0000] rev 30690
chg: decouple hgclient from setupsignalhandler procutil should not depend on hgclient. This patch makes the signal handling part independent from hgclient.
Mon, 02 Jan 2017 14:02:47 +0000 chg: move signal and pager handling to a separate file
Jun Wu <quark@fb.com> [Mon, 02 Jan 2017 14:02:47 +0000] rev 30689
chg: move signal and pager handling to a separate file In the future hgclient will deal with pager directly inside runcommand, so related signal handling stuff needs to be decoupled from chg.c. The signal handling and pager logic are coupled because we need to forward SIGPIPE when pager exits. So they are moved together, otherwise a global variable (pagerpid) is inevitable. This patch moves related functions from chg.c to procutil.c, which was marked as copied to maintain annotate history. The move is done without code modification for easy review, therefore `#include "procutil.c"` was introduced temporarily.
Wed, 07 Oct 2015 16:02:45 -0700 keepalive: rewrite readline()
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Oct 2015 16:02:45 -0700] rev 30688
keepalive: rewrite readline() The old method was performing string concatenation, which is slower than collecting raw chunks in a list and joining at the end.
Wed, 07 Oct 2015 15:53:58 -0700 keepalive: remove limit argument from readline()
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Oct 2015 15:53:58 -0700] rev 30687
keepalive: remove limit argument from readline() It is unused and adds complexity.
Wed, 07 Oct 2015 15:33:52 -0700 keepalive: don't concatenate strings when reading chunked transfer
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Oct 2015 15:33:52 -0700] rev 30686
keepalive: don't concatenate strings when reading chunked transfer Surprisingly, this didn't appear to speed up HTTP-based stream cloning on my machine. I suspect this has more to do with the fact we're using small HTTP chunks and string concatenation overhead isn't so bad. However, the reasons for this change are solid: we know string concatenation can be a performance sink.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip