On Wed, 21 Dec 2016 15:39:05 +0000, Jun Wu wrote:
> Actually, patch 1 is unnecessary if we go with the "ui._runpager" approach.
> Maybe someone can drop it without adding too many markers.
Previously, the "system" channel is inside the ui object. In the future, chg
will let dispatch to create a new ui object from scratch, to maximize
compatibility. And chgserver will use a "uisetup" like an extension to wrap
ui.system. To be able to do that cleanly, the system channel needs to be
accessed directly.
Previously, the hash address is just appending "-$HASH" to base address.
This patch makes it truncate the basename address at "." before appending
"-$HASH".
This makes it possible to spawn new servers in a racy situation and the
client could be sure the server it connects is the new server just spawned.
This is a step towards removing the lock.
One of the functionalities of the lock is to make sure the connect will
connect to a server it just created:
1. start server --address foo
2. connect to foo # wish "foo" is the server just started
With this change, the client could do:
1. start server --address foo.tmp$PID
2. connect to foo.tmp$PID # is the server just started
(note: if it is not, it does not affect correctness - linux pid
namespace is not a concern here)
3. rename foo.tmp$PID to foo
Another functionality of the lock is to avoid starting multiple servers with
a same confighash in parallel. But that also prevents starting multiple
servers with different confighashes in parallel.
The environment variables `HG_*` are usually used by hooks. Unlike `HGPLAIN`
etc, they do not actually affect hg's behavior. So do not include them in
confighash.
This would avoid spawning an unbound number of chg server processes if
commit hook calls hg frequently.
It was an extension just because there were several dependency cycles I
needed to address.
I don't add 'chgserver' to extensions._builtin since chgserver is considered
an internal extension so nobody should enable it by their config.
