Wed, 24 Feb 2016 20:45:47 +0000 chgserver: add a structure for confighash and mtimehash
Jun Wu <quark@fb.com> [Wed, 24 Feb 2016 20:45:47 +0000] rev 28277
chgserver: add a structure for confighash and mtimehash confighash and mtimehash are often used together. This patch adds a simple structure called hashstate to store them. hashstate also has a handly method called fromui to calculate the hashes from a ui object.
Fri, 26 Feb 2016 14:59:39 +0000 chgserver: add utilities to calculate mtimehash
Jun Wu <quark@fb.com> [Fri, 26 Feb 2016 14:59:39 +0000] rev 28276
chgserver: add utilities to calculate mtimehash mtimehash is designed to detect file changes. These files include: - single file extensions (__init__.py for complex extensions) - mercurial/__version__.py - python (sys.executable) mtimehash only uses stat to check files so it's fast but not 100% accurate. However it should be good enough for our use case. For chgserver, once mtimehash changes, the server is considered outdated immediately and should no longer provide service.
Sat, 27 Feb 2016 17:31:23 +0100 tests: rename 'test-module-import.t' into 'test-check-module-import.t'
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 27 Feb 2016 17:31:23 +0100] rev 28275
tests: rename 'test-module-import.t' into 'test-check-module-import.t' This test is checking our source code to ensure style and correct behavior (eg: no cycle). Current convention is that such tests starts with 'test-check-' so we flock this on back with the others.
Fri, 26 Feb 2016 20:22:05 +0900 pull: deactivate a bookmark not matching with the destination of the update
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Feb 2016 20:22:05 +0900] rev 28274
pull: deactivate a bookmark not matching with the destination of the update Before this patch, "hg pull -u" with a target doesn't deactivate a current active bookmark, which doesn't match with the explicit destination of the update, even though bare "hg update" does so. A "target" can be provided through: - option --rev ANOTHER - option --branch ANOTHER - source URL#ANOTHER
Fri, 26 Feb 2016 20:22:05 +0900 pull: activate a bookmark matching with the destination of the update (BC)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Feb 2016 20:22:05 +0900] rev 28273
pull: activate a bookmark matching with the destination of the update (BC) Before this patch, "hg pull -u" with a target doesn't activate a bookmark, which matches with the explicit destination of the update, even though bare "hg update" does so. A "target" can be provided through: - option --rev BOOKMARK - source URL#BOOKMARK
Sat, 13 Feb 2016 20:13:45 +0900 revset: define "pat" variable unconditionally in subrepo()
Yuya Nishihara <yuya@tcha.org> [Sat, 13 Feb 2016 20:13:45 +0900] rev 28272
revset: define "pat" variable unconditionally in subrepo() It's a source of UnboundLocalError to define and use local variables conditionally. As getstring() always returns a str, "pat" can be initialized to None.
Tue, 05 May 2015 10:47:35 +0900 revset: drop translation markers from error messages of internal _matchfiles
Yuya Nishihara <yuya@tcha.org> [Tue, 05 May 2015 10:47:35 +0900] rev 28271
revset: drop translation markers from error messages of internal _matchfiles They are a sort of debug messages, which should never be visible to end users.
Fri, 12 Feb 2016 19:16:09 +0900 templatekw: switch ctx of list expression to rev of {parents} (BC)
Yuya Nishihara <yuya@tcha.org> [Fri, 12 Feb 2016 19:16:09 +0900] rev 28270
templatekw: switch ctx of list expression to rev of {parents} (BC) This is the same semantics as revset() introduced at e4609ec959f8. Before this patch, {parents} provided nothing useful in new-style template. For example, '{parents % "{parent}"}' generated cryptic string like "rev12345node0123abcdef...". This patch drops {parent} variable since it was useless. We can get a revision number by '{parents % "{rev}"}'.
Fri, 26 Feb 2016 20:22:05 +0900 commands: add postincoming explicit brev argument (API)
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.
Sat, 27 Feb 2016 19:53:18 +0800 hgweb: add index template to json/map
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.
Fri, 26 Feb 2016 19:13:10 +0000 merge: fix error message
Simon Farnsworth <simonfar@fb.com> [Fri, 26 Feb 2016 19:13:10 +0000] rev 28267
merge: fix error message Obvious copy-and-paste error
Wed, 24 Feb 2016 23:00:33 +0900 destutil: show message about other branch heads, even if on a closed head
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.
Wed, 24 Feb 2016 06:10:46 +0900 repoview: discard filtered changelog if index isn't shared with unfiltered
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.
Fri, 26 Feb 2016 15:22:46 +0000 chgserver: make _renewui load repo and command line configs
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.
(0) -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip