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.
Fri, 26 Feb 2016 15:07:58 +0000 dispatch: add wd parameter to _getlocal
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).
Fri, 26 Feb 2016 14:50:04 +0000 chgserver: add utilities to calculate confighash
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.
Fri, 26 Feb 2016 14:13:12 +0000 chg: detect chg started by chg
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.
Fri, 26 Feb 2016 14:17:59 +0000 chg: fallback to original hg for some unsupported commands or flags
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.
Wed, 24 Feb 2016 13:20:06 +0000 testing: add a 'continuous' profile
David R. MacIver <david@drmaciver.com> [Wed, 24 Feb 2016 13:20:06 +0000] rev 28259
testing: add a 'continuous' profile This gives a good way of letting Hypothesis run until it finds an error, save that error, and be restarted without it picking up on the old bug. This lets you run long-running Hypothesis processes and then perform a manual deduplication task on the bugs found at the end. It's not an entirely satisfying way of using this, but anything much better would require extensive changes to Hypothesis itself.
Wed, 24 Feb 2016 13:11:30 +0000 testing: allow Hypothesis to enable extensions
David R. MacIver <david@drmaciver.com> [Wed, 24 Feb 2016 13:11:30 +0000] rev 28258
testing: allow Hypothesis to enable extensions This adds support for testing extensions, including both tests that extensions don't change behaviour and test for specific commands. We use the precondition system to determine what commands are available to us. If we never use any commands enabled by an extension then that extension is *skippable* and should not have changed the behaviour of the test. We thus rerun the test with an environment variable which is designed to turn off the extension.
Fri, 26 Feb 2016 17:24:14 +0000 testing: test multiple repositories with Hypothesis
David R. MacIver <david@drmaciver.com> [Fri, 26 Feb 2016 17:24:14 +0000] rev 28257
testing: test multiple repositories with Hypothesis This expands the Hypothesis based stateful testing so that rather than having a single repository under test, Hypothesis manages a family of repositories. Some of these are freshly created, some are clones of others.
Wed, 24 Feb 2016 13:06:43 +0000 testing: expand Hypothesis tests with branch commands
David R. MacIver <david@drmaciver.com> [Wed, 24 Feb 2016 13:06:43 +0000] rev 28256
testing: expand Hypothesis tests with branch commands This builds on the previous work to add Hypothesis based stateful testing to add branching commands to the model.
Wed, 24 Feb 2016 13:05:45 +0000 testing: generate tests operations using Hypothesis
David R. MacIver <david@drmaciver.com> [Wed, 24 Feb 2016 13:05:45 +0000] rev 28255
testing: generate tests operations using Hypothesis The idea of this patch is to expand the use of Hypothesis within Mercurial to use its concept of "stateful testing". The result is a test which runs a sequence of operations against a Mercurial repository. Each operation is given a set of allowed ways it can fail. Any other non-zero exit code is a test failure. At the end, the whole sequence is then reverified by generating a .t test and testing it again in pure mode (this is also useful for catching non-determinism bugs). This has proven reasonably effective at finding bugs, and has identified two problems in the shelve extension already (issue5113 and issue5112).
Mon, 29 Feb 2016 22:52:29 +0900 i18n-ja: synchronized with cb6a952efbf4 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 29 Feb 2016 22:52:29 +0900] rev 28254
i18n-ja: synchronized with cb6a952efbf4
Mon, 15 Feb 2016 22:46:07 +0900 log: fix order of revisions filtered by multiple OR options (issue5100) stable
Yuya Nishihara <yuya@tcha.org> [Mon, 15 Feb 2016 22:46:07 +0900] rev 28253
log: fix order of revisions filtered by multiple OR options (issue5100) This is the simplest workaround for the issue of the ordering of revset, which is that the expression "x or y" takes over the ordering specified by the input set (or the left-hand-side expression.) For example, the following expression A & (x | y) will be evaluated as if (A & x) | (A & y) That's wrong because revset has ordering. I'm going to fix this problem in the revset module, but that wouldn't fit to stable. So, this patch just works around the common log cases. Since this change might have some impact on performance, it is enabled only if the expression built from log options has ' or ' operation.
Thu, 25 Feb 2016 22:35:11 -0800 demandimport: add _imp to ignore list stable
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 25 Feb 2016 22:35:11 -0800] rev 28252
demandimport: add _imp to ignore list Mozilla is seeing an issue with demand importing of _imp failing in pkg_resources/__init__.py:fixup_namespace_packages. It strangely only reproduces when using a modern version of setuptools/pip in certain scenarios. Adding _imp to the demand import ignore list seems to make the problem go away.
Thu, 25 Feb 2016 16:54:14 +0000 tests: rename regression tests
timeless <timeless@mozdev.org> [Thu, 25 Feb 2016 16:54:14 +0000] rev 28251
tests: rename regression tests
Thu, 25 Feb 2016 10:01:59 -0800 zeroconf: fix crash in "hg paths" when zeroconf server is up
Danek Duvall <danek.duvall@oracle.com> [Thu, 25 Feb 2016 10:01:59 -0800] rev 28250
zeroconf: fix crash in "hg paths" when zeroconf server is up Running "hg paths" with zeroconf enabled and when a zeroconf server is up and running gives a traceback with "ValueError: rawloc must be defined". This is because zeroconf needs to wrap ui.configsuboptions(), introduced in dccbebcff075.
Wed, 24 Feb 2016 22:22:18 -0800 zeroconf: fix setsockopt() call on Solaris to send payload of correct length
Danek Duvall <danek.duvall@oracle.com> [Wed, 24 Feb 2016 22:22:18 -0800] rev 28249
zeroconf: fix setsockopt() call on Solaris to send payload of correct length The zeroconf extension has been broken on Solaris since the beginning, but no one noticed until the testsuite started poking it after changeset 72f2a19c5f88, when it started running "hg paths" with the extension enabled. Solaris requires that, for IP_MULTICAST_{TTL,LOOP}, the argument passed in be of length 1. With the original code here, it gets passed in as an int -- length 4 -- and so the system call fails with EINVAL. Thankfully, Python's socket.setsockopt() allows you to pass in a string instead of an integer, and it passes that string to libc's setsockopt() with the correct value and length.
Wed, 03 Feb 2016 04:54:40 +0000 blackbox: properly replace ui class
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 04:54:40 +0000] rev 28248
blackbox: properly replace ui class Without this, anyone creating a ui object using: uimod.ui() skips the blackbox. Also, anyone doing ui.copy() skipped the blackbox. Unfortunately, the ui object lifestyle is a bit messy, the first one that's created is never actually initialized with subclasses, instead pieces of the subclass are adopted into the primal ui object. In order to handle this, a _partialinit method will be called to ensure that the blackboxui is properly initialized.
Wed, 03 Feb 2016 17:05:04 +0000 blackbox: store the blackbox ui object instead of the log file
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 17:05:04 +0000] rev 28247
blackbox: store the blackbox ui object instead of the log file Without this, the last logged entry didn't have access to the repository, and thus couldn't report its version (and especially that an add or similar dirtied it). A side-effect is that one repo leaks until process exit...
Tue, 09 Feb 2016 15:44:13 +0000 blackbox: log dirty state
timeless <timeless@mozdev.org> [Tue, 09 Feb 2016 15:44:13 +0000] rev 28246
blackbox: log dirty state If blackbox.dirty = True, use `+` to indicate dirty repositories.
Tue, 09 Feb 2016 19:16:06 +0000 blackbox: log working directory version
timeless <timeless@mozdev.org> [Tue, 09 Feb 2016 19:16:06 +0000] rev 28245
blackbox: log working directory version Without this, while you could see the list of commands run, it wasn't possible to identify what they were doing, because commads could rely on revsets (including remote input which varies over time).
Mon, 08 Feb 2016 03:37:26 +0000 blackbox: rename fp variable
timeless <timeless@mozdev.org> [Mon, 08 Feb 2016 03:37:26 +0000] rev 28244
blackbox: rename fp variable
Wed, 03 Feb 2016 15:41:31 +0000 blackbox: avoid creating multiple file handles for a single log
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 15:41:31 +0000] rev 28243
blackbox: avoid creating multiple file handles for a single log There are multiple ui objects in Mercurial that can relate to a repository, before this change, each one would have its own file pointer, which results in unfortunate logging behavior. Also, any log rotation results would be bad because only the active blackboxui object's file pointer would be refreshed. Note that this does not prevent two long running hg commands for the same repository from causing problems.
Wed, 24 Feb 2016 20:04:32 +0000 tests: mock getpid to reduce glob usage
timeless <timeless@mozdev.org> [Wed, 24 Feb 2016 20:04:32 +0000] rev 28242
tests: mock getpid to reduce glob usage Updating tests based on ac49ecb2a897.
Mon, 22 Feb 2016 14:43:14 -0800 changegroup: drop special-casing of flat manifests
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Feb 2016 14:43:14 -0800] rev 28241
changegroup: drop special-casing of flat manifests Since c08814b48ae5 (changegroup: avoid iterating the whole manifest, 2015-12-04), the manifest linkrev callback iterates over only the files that were touched according the the changeset. Before that change, we iterated over all files returned in manifest.readfast(). That method returns the files in the delta, if the delta parent is a parent, otherwise it returns the full manifest. Most manifest revisions end up using one of the parents as its delta parent, so most of the time, the method returns a short manifest. It seems that that happens often enough that it doesn't really matter; I could not reproduce the timings reported in that change. Since the treemanifest code now works quite differently, and since that code also works correctly for flat manifests, let's drop the special-casing of flat manifests.
Fri, 12 Feb 2016 23:09:09 -0800 changegroup: fix treemanifests on merges
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Feb 2016 23:09:09 -0800] rev 28240
changegroup: fix treemanifests on merges The current code for generating treemanifest revisions takes the list of files in the changeset and finds the directories from them. This does not work for merges, since a merge may pick file A from one side and file B from another and neither of them would appear in the changeset's "files" list, but the manifest would still change. Fix this by instead walking the root manifest log for all needed revisions, storing all needed file and subdirectory revisions, then recursively visiting the subdirectories. This also turns out to be faster: cloning a version of hg core converted to treemanifests went from ~28s to ~19s (timing somewhat unfair: before this patch, timed until crash; after this patch, timed until manifests complete). The new algorithm is used only on treemanifest repos. Although it works equally well on flat manifests, we leave the iteration over files in the changeset for flat manifests for now.
(0) -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip