FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Feb 2016 20:22:05 +0900] rev 28269
commands: add postincoming explicit brev argument (API)
Before this patch, postincoming() initializes 'brev' with 'checkout',
but this isn't useful to activate/deactivate bookmark after updating,
because 'checkout' is not a string actually specified at command line,
but an already node-nized byte sequence.
This patch adds postincoming() explicit 'brev' argument, and makes
'pull()' pass appropriate value.
This patch adds 'brev' argument instead of 'brev=None', because
'brev=None' isn't reasonable value if checkout is not None.
Anton Shestakov <av6@dwimlabs.net> [Sat, 27 Feb 2016 19:53:18 +0800] rev 28268
hgweb: add index template to json/map
This template allows showing the list of all repos in an hgweb instance (in
hgwebdir mode) as json.
The test has "lastchange" globbed because hgweb uses here file modification
time and not the last commit time.
Simon Farnsworth <simonfar@fb.com> [Fri, 26 Feb 2016 19:13:10 +0000] rev 28267
merge: fix error message
Obvious copy-and-paste error
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 24 Feb 2016 23:00:33 +0900] rev 28266
destutil: show message about other branch heads, even if on a closed head
Before this patch, bare "hg update" displays message below, if there
is at least one non-closed branch head other than current parent:
1. 'XX other heads for branch "BRANCH"' message, if current parent is
on a non-closed branch head
This suggests user to invoke "hg heads" or so for merging them.
2. no message, if current parent is on a closed branch head
At this patch, bare "hg update" might choose closed branch head
as update destination, and it causes this situation easily.
3. no message, otherwise (= current parent isn't on any branch head)
'XX other heads for branch "BRANCH"' should be displayed also in #2
case above, because user might overlook other non-closed branch heads.
This patch gets a list of all branch heads regardless of closed-ness
of it, and uses it (= 'allheads') to distinguish #1/#2 from #3 above.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 24 Feb 2016 06:10:46 +0900] rev 28265
repoview: discard filtered changelog if index isn't shared with unfiltered
Before this patch, revisions rollbacked at failure of previous
transaction might be visible at subsequent operations unintentionally,
if repoview object is reused even after failure of transaction:
e.g. command server and HTTP server are typical cases.
'repoview' uses the tuple of values below of unfiltered changelog as
"the key" to examine validity of filtered changelog cache.
- length
- tip node
- filtered revisions (as hashed value)
- '_delayed' field
'repoview' compares between "the key" of unfiltered changelog at
previous caching and now, and reuses filtered changelog cache if no
change is detected.
But this comparison indicates only that there is no change between
unfiltered 'repo.changelog' at last caching and now, but not that
filtered changelog cache is valid for current unfiltered one.
'repoview' uses "shallow copy" of unfiltered changelog to create
filtered changelog cache. In this case, 'index' buffer of unfiltered
changelog is also referred by filtered changelog.
At failure of transaction, unfiltered changelog itself is invalidated
(= un-referred) on the 'repo' side (see
0a7610758c42 also). But
'index' of it still contains revisions to be rollbacked at this
failure, and is referred by filtered changelog.
Therefore, even if there is no change between unfiltered
'repo.changelog' at last caching and now, steps below makes rollbacked
revisions visible via filtered changelog unintentionally.
1. instantiate unfiltered changelog as 'repo.changelog'
(call it CL1)
2. make filtered (= shallow copy of) CL1
(call it FCL1)
3. cache FCL1 with "the key" of CL1
4. revisions are appended to 'index', which is shared by CL1 and FCL1
5. invalidate 'repo.changelog' (= CL1) at failure of transaction
6. instantiate 'repo.changelog' again at next operation
(call it CL2)
CL2 doesn't have revisions added at (4), because it is
instantiated from '00changelog.i', which isn't changed while
failed transaction.
7. compare between "the key" of CL1 and CL2
8. FCL1 cached at (3) is reused, because comparison at (7) doesn't
detect change between CL1 at (1) and CL2
9. revisions rollbacked at (5) are visible via FCL1 unintentionally,
because FCL1 still refers 'index' changed at (4)
The root cause of this issue is that there is no examination about
validity of filtered changelog cache against current unfiltered one.
This patch discards filtered changelog cache, if its 'index' object
isn't shared with unfiltered one.
BTW, at the time of this patch, redundant truncation of
'00changelog.i' at failure of transaction (see
0a7610758c42 for
detail) often prevents "hg serve" from making already rollbacked
revisions visible, because updating timestamps of '00changelog.i' by
truncation makes "hg serve" discard old repoview object with invalid
filtered changelog cache.
This is reason why this issue is overlooked before this patch, even
though test-bundle2-exchange.t has tests in similar situation: failure
of "hg push" via HTTP by pretxnclose hook on server side doesn't
prevent subsequent commands from looking up outgoing revisions
correctly.
But timestamp on the filesystem doesn't have enough resolution for
recent computation power, and it can't be assumed that this avoidance
always works as expected.
Therefore, without this patch, this issue might appear occasionally.
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 15:22:46 +0000] rev 28264
chgserver: make _renewui load repo and command line configs
Before this patch, there is no way to load repo config in chgserver. This
patch revised _renewui to let it load repo config and take command line
flags passed into consideration.
The _renewui logic is not ideal at present because it's very tricky to know
what should copy and what should not from the old ui object to the new one.
This is partially because the current ui and config object design is not
ideal. In the future, we may want to avoid all ui or config copies.
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 15:07:58 +0000] rev 28263
dispatch: add wd parameter to _getlocal
Before this patch, _getlocal uses os.getcwd() to locate repo in current dir.
chgserver needs it to load repo config and has to do chdir twice: the first
is to set current directory and the second is to redo the side effect (in case
hg --cwd some/relative/path, chdir will be called again in dispatch later),
which is not pretty.
This patch adds an optional wd parameter to make it possible to specify wd
without chdir (and its side effect).
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 14:50:04 +0000] rev 28262
chgserver: add utilities to calculate confighash
confighash is the hash of sensitive config items like [extensions], and
sensitive environment variables like HG*, LD_*, etc. The config items
can come from global, user, repo config, and command line flags.
For chgserver, it is designed that once confighash changes, the server is
not qualified to serve its client and should redirect the client to a new
server. The server does not need to exit in this case, since it can still
be valid (have a matched confighash) to serve other chg clients.
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 14:13:12 +0000] rev 28261
chg: detect chg started by chg
Sometimes people may create a symbol link from hg to chg, or write a wrapper
script named hg calling chg. Without $HG and $CHGHG set, this will lead to
chg executes itself causing deadlock. The user will notice chg hangs for some
time and aborts with a timed out message, without knowing the root cause and
how to solve it.
This patch sets a dummy environment variable before executing hg to detect
this situation, and print a fatal message with some possible solutions.
CHGINTERNALMARK is set by chg client to detect the situation that chg is
started by chg. It is temporary and should be dropped to avoid possible
side effects.
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 14:17:59 +0000] rev 28260
chg: fallback to original hg for some unsupported commands or flags
There are some known unsupported commands or flags for chg, such as hg serve -d
and hg foo --time. This patch detects these situations and transparently fall
back to the original hg. So the users won't bother remembering what chg can and
cannot do by themselves.
The current detection is not 100% accurate since we do not have an equivalent
command line parser in C. But it tries not to cause false positives that
prevents people from using chg for legit cases. In the future we may want to
implement a more accurate "unsupported" check server-side.