Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 15:57:28 +0900] rev 39968
rust-chg: update dependencies
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 15:54:18 +0900] rev 39967
rust-chg: add project skeleton
This directory will host the reimplementation of cHg in Rust. It will use
Tokio [1], and tokio-hglib [2] which I wrote for an oxidized CHg, no idea
if there's such carbon bonding in nature btw.
[1]: https://tokio.rs/
[2]: https://bitbucket.org/yuja/tokio-hglib/
The reasoning for depending on Tokio is that it will allow us to handle Unix
signals in a safer way. Well, I believed that until I found a weird function,
handlestopsignal(), in cHg codebase. It resends the same signal to the same
process by temporarily masking the handler, which can't be inherently async.
So the signal handlers will stay in C, which means there isn't actually much
reason to write async code right now, other than I've already done most of
the async stuff, and slightly easier pager handling.
The reasoning for the rewrite is that it will eventually be possible to port
server-side config validation back to the client side, which will reduce
the complexity of the current daemon management. It will also encourage us
to write frontend library (e.g. command line and config parsers) in Rust.
The license is GPL2+ because it's likely to include derived work from the
cHg of C. The rust/chg crate is excluded from the root workspace as it's
unclear how the whole rust packages should be laid out. That can be revisited
later.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 12:56:57 -0700] rev 39966
narrow: move copies overrides to core
The copies overrides seems to have been a little complicated just by
not being in core. When moved to core, it becomes trivial (at least I
think these overrides have the same effect).
Differential Revision: https://phab.mercurial-scm.org/D4825
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 18:45:16 +0300] rev 39965
narrow: pass old includes and excludes to _widen()
In future patches we will need to pass them in the widen wireprotocol command
which we are building.
Differential Revision: https://phab.mercurial-scm.org/D4812
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 28 Sep 2018 23:53:09 +0300] rev 39964
narrow: check for servers' narrow support before doing anything (BC)
Recently we introduced narrow capabilities for the server. So we can check
whether a server has narrow clone support or not before doing anything. This is
BC because new clients won't be able to extend from old narrow-enabled servers.
I *think* narrow is not used much (maybe just inside Google), also it's
experimental so I think we can change this. We will need to this someday anyway.
The "doesn't" in error is changed to "does not" because I think that's we do in
core. I also changed one more instance of the error message to use 'does not'
for consistency.
Differential Revision: https://phab.mercurial-scm.org/D4789
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 18:59:27 +0300] rev 39963
narrow: don't do the dirstate dance if ellipses is not enabled
I believe we set dirstate parents to nullid before widening pull because in
ellipses cases, the parent might be stripped off with a new changeset. However
the second ds.setparents() call invalidate my assumption. I am not sure why we
do this. So here is a patch.
This patch also adds tests showing we break nothing in non-ellipses cases.
Differential Revision: https://phab.mercurial-scm.org/D4788
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 28 Sep 2018 19:21:24 +0300] rev 39962
narrow: pass 'narrow_widen' as source while generating changegroup
Extensions inspect the `source` parameter and add some custom logic on the basis
of value of that parameter. The parameter is also passed to hooks. So let's pass
the value as 'narrow_widen' to differentiate widening from pull.
Differential Revision: https://phab.mercurial-scm.org/D4787
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 28 Sep 2018 19:18:17 +0300] rev 39961
narrow: factor out logic to create cg while widening into separate fn
This patch takes out the logic which generates a changegroup for widening a
narrow clone when ellipses are disabled. This is done because future patches
will introduce a narrow_widen() wireprotocol command which will send a
bundle2 with changegroup and will use this function.
The new function for now returns just the changegroup for compatibility with
existing code, but in future patches, when we establish a wireprotocol command
and call this function from there, this will return the required bundle2.
Differential Revision: https://phab.mercurial-scm.org/D4786
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Oct 2018 15:29:31 -0700] rev 39960
narrow: avoid looking up dirstate again when editing dirstate
The narrow extension overrides the dirstate editing functions to
restrict paths outside the narrowspec. These overrides access the
dirstate from repo.dirstate instead of using the "self" reference
passed to the overridden functions. I don't see a reason for this and
it caused me problems with a later patch (it caused infinite recursion
when I modified localrepo.dirstate()), so let's change it.
Differential Revision: https://phab.mercurial-scm.org/D4829
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Sep 2018 23:09:28 -0700] rev 39959
repo: move unfiltered-repo optimization to workingctx
localrepo.__getitem__ special-cased lookup of the working copy parent
to avoid looking up obsmarkers. I think the reason for that code
(which I once wrote myself) was to make `hg commit` not load
obsmarkers, which it would otherwise do via ctx.p1() in
localrepo.commitctx().
That had the somewhat unfortunate consequence of making lookup of an
unrelated binary nodeid load the dirstate. Now that changectx's
constructor is dumb, we can let workingctx._parents() have the
opmtimization instead.
This affects two tests, because they no longer end up loading the
dirstate and their "warning: ignoring unknown working parent ..."
messages therefore go way.
Differential Revision: https://phab.mercurial-scm.org/D4828