bookmarks: display the obsfate of hidden revision we create a bookmark on Display the same message we added recently to the filtered error message create a bookmark on an hidden revision. Differential Revision: https://phab.mercurial-scm.org/D1870

update: display the obsfate of hidden revision we update to Display the same message we added recently to the filtered error message when updating to a hidden obsolete changeset. Differential Revision: https://phab.mercurial-scm.org/D1869

evolution: make reporting of new unstable changesets optional This makes it possible to turn off the reporting of unstable changesets (e.g. "1 new orphan changesets"), just in case it's too slow for some users. Anyone who's been using the evolve extension has already been accepting the cost of the reporting, so this is just for the few users who have turned on obsmarkers but not been using the evolve extension (as I believe Facebook has). Differential Revision: https://phab.mercurial-scm.org/D1868

evolution: report new unstable changesets This adds a transaction summary callback that reports the number of new orphan, content-divergent and phase-divergent changesets. The code for reporting it is based on the code from the evolve extension, but simplified a bit. It simply counts the numbers for each kind of instability before and after the transaction. That's obviously not very efficient, but it's easy to reason about, so I'm doing this as a first step that can make us quite confident about the test case changes. We can optimize it later and make sure that the tests are not affected. The code has been used in the evolve extension for a long time and has apparently been sufficiently fast, so it doesn't seem like a pressing issue. Unlike the evolve extension's version of this report, this version applies to all commands (or all transactions run as part of any command, to be exact). Differential Revision: https://phab.mercurial-scm.org/D1867

transaction: register summary callbacks only at start of transaction (BC) We currently register summary callbacks every time localrepo.transaction() is called, so both when the transaction is started and when a nested transaction is created. That seems a little weirdly asymmetric, because the summary callbacks are thus not necessarily registred at the beginning of the outermost transaction, but they are only called when the outermost transaction closes (not when a nested transaction closes). I want to add another summary callback that records the repo state at the beginning of the transaction and compares to that when the transaction closes. However, because of the registration that happens when a nested transaction is created, that would need to go through extra trouble to not overwrite the callback and report the difference from the start time of the innermost transaction to the close of the outermost transaction. Also, the callbacks are registered with a name based on the order they are defined in the registersummarycallback(). For example, if both the "new changesets %s" and the "obsoleted %i changesets" hooks are registered, the first would be called 00-txnreport and the second would be called 01-txnreport. That gets really weird if registersummarycallback() gets called multiple times, because the last one wins, and a depending on which of the two callbacks get registered, we might hypothetically even overwrite on type of callback with another. For example, if when the outer transaction was started, we registered the "new changesets %s" callback first, and when the inner transaction was started, we registered only the "obsoleted %i changesets" callback, then only the latter message would get printed. What makes it hypothetical is that what gets registered depends on the transaction name, and the set of transaction names that we match on for the former latter message is a subset of the set of names we match on for the former. Still, that seems like a bug waiting to happen. That second issue could be solved independently, but the first issue seems enough for me to consider it a bug (affecting developers, not users), so this patch simply drops that extra registration. Note that this affects "hg transplant" in a user-visible way. When "hg transplant" is asked to transplant from a remote repo so it involves a pull, then the outermost transaction name is "transplant" and an inner transaction is created for "pull". That inner transaction is what led us to sometimes report "new changesets %s" from "hg transplant". After this patch, that no longer happens. That seems fine to me. We can make it instead print the message for all "hg transplant" invocations if we want (not just those involving a remote), but I'll leave that for someone else to do if they think it's important. Differential Revision: https://phab.mercurial-scm.org/D1866

repair: filter out unknown revisions from phasecache within transaction I'm about to add another summary report callback that needs to access phase information. These callbacks run at the end of the transaction and some of them failed because they tried to get the phase for stripped commits. The solution is to filter out unknown revisions before the transaction is closed. Differential Revision: https://phab.mercurial-scm.org/D1865

repair: drop unnecessary phase cache invalidation After stripping the revlogs, we have been invalidating the phase cache since bf7b8157c483. Later, in 8e3021fd1a44, I added a call to phasecache.filterunknown(). I apparently didn't realize it then, but I now think that that call made the existing phasecache.invalidate() call unnecessary, so this patch drops it. Both the test added in bf7b8157c483 and the entire evolve extension test suite indeed still pass. Differential Revision: https://phab.mercurial-scm.org/D1864

wireproto: drop support for reader interface from streamres (API) 2add671bf55b and later commits overhauled support for compression and output handling in the wire protocol. Fast forward 14 months and all wire protocol commands except the legacy "changegroup" and "changegroupsubset" commands feed a generator to streamres. I no longer think it is worth maintaining support for the old "reader" API (which allows you to specify an object having a read() method to obtain data). This commit refactors the legacy wire protocol commands to feed a generator to the streamres. We also drop support for the "reader" argument and the code that was using it. As part of the change, chunks over the SSH protocol have increased in size for these commands. But these commands are really ancient, so I doubt anyone will notice. .. api:: wireproto.streamres.__init__ no longer accepts a "reader" argument. Use the "gen" argument instead. Differential Revision: https://phab.mercurial-scm.org/D1861