caches: introduce a function to warm cache We have multiple caches that gain from being kept up to date. For example in a server setup, we want to make sure the branchcache cache is hot for other read-only clients. Right now each cache tries to update themself in place where new data have been added. However the approach is error prone (we might miss some spot) and fragile. When nested transaction are involved, such cache updates might happen before a top level transaction is committed. Writing caches for uncommitted data on disk. Having a single entry point, run at the end of each successful transaction, helps to ensure the cache is up to date and refreshed at the right time. We start with updating the branchmap cache but other will come.

transaction: track newly introduced revisions Tracking revisions is not the data that will unlock the most new capability. However, they are the simplest thing to track and still unlock some nice improvements in regard with caching. We plug ourself at the changelog level to make sure we do not miss any revision additions. The 'revs' set is configured at the repository level because the transaction itself does not needs to know that much about the business logic.

transaction: introduce "changes" dictionary to precisely track updates The transaction is already tracking some data intended for hooks (in 'hookargs'). However, that information is minimal as we optimise for passing data to other processes through environment variables. There are multiple places were we could use more complete and lower level information locally (eg: cache update, better report of changes to hooks, etc...). For this purpose we introduces a 'changes' dictionary on the transaction. It is intended to track every changes happening to the repository (eg: new revs, bookmarks move, phases move, obs-markers, etc). For now we just adds the 'changes' dictionary. We'll adds more tracking and usages over time.

clone: add a server-side option to disable full getbundles (pull-based clones) For large enough repositories, pull-based clones take too long, and an attempt to use them indicates some sort of configuration or other issue or maybe an outdated Mercurial. Add a config option to disable them.

clone: warn when streaming was requested but couldn't be performed This helps both users and the people who support them figure out why a stream clone couldn't be performed. In an upcoming patch we're going to add a way for servers to hard abort on a full getbundle. In those cases servers might expect clients to perform a stream clone, so it's important to communicate why one couldn't be done.

clone: test streaming disabled because client is missing requirement Turns out we had no coverage for this important case.

bundle2: don't check for whether we can do stream clones At the moment this isn't used and all stream clones use the legacy protocol. In an upcoming diff, canperformstreamclone will print out a message if a stream clone was requested but couldn't happen for some reason. Removing this call ensures the message isn't printed twice.

debugcommands: add debugpickmergetool to examine which merge tool is chosen Before this patch, there is no convenient way to know which merge tool is chosen for each managed files without actual merging.

filemerge: add internal merge tool to dump files forcibly Internal merge tool :dump implies premerge. Therefore, files aren't dumped, if premerge runs successfully. This undocumented behavior might confuse users, if they want to always dump files. But just making :dump omit premerge might cause backward compatibility issue for existing automation. This patch adds new internal merge tool :forcedump, which works as same as :dump, but omits premerge always. Internal tools annotated with "nomerge" should merge "change and delete" correctly, but _forcedump() can't. Therefore, it is annotated with "mergeonly" to always omit premerge, even though it doesn't merge files actually. This patch also adds explanation about premerge to :dump, to clarify how :dump actually works. BTW, this patch specifies internal tools with "internal:" prefix in newly added test scenario in test-merge-tools.t, even though this prefix is already deprecated. This is only for similarity to other tests in test-merge-tools.t.

filemerge: make warning message more i18n friendly Before this patch, " specified for " part of warning messages (e.g. "couldn't find merge tool TOOL specified for PAT") isn't translatable.

filemerge: show warning about choice of :prompt only at an actual fallback Before this patch, internal merge tool :prompt shows "no tool found to merge FILE" line, even if :prompt is explicitly specified as a tool to be used. This patch shows warning message about choice of :prompt only at an actual fallback, in which case any tool is rejected by capability for binary or symlink. It is for backward compatibility to omit warning message in "changedelete" case.

treemanifest: allow manifestrevlog to take an explicit treemanifest arg Previously we relied on the opener options to tell the revlog to be a tree manifest. This makes it complicated for extensions to create treemanifests and normal manifests at the same time. Let's add a construtor argument to create a treemanifest revlog as well. I considered removing the options['treemanifest'] logic from manifestrevlog entirely, but doing so shifts the responsibility to the caller which ends up requiring changes in localrepo, bundlerepo, and unionrepo. I figured having the dual mechanism was better than polluting other parts of the code base with treemanifest knowledge.

policy: relax the default for in-place build We're going to make the 'c' policy more strict, where no missing attribute will be allowed. Since we want to run 'hg bisect' without rebuilding the C extension modules, we'll need a looser policy for development environment. The default for system installation isn't changed. Note that the current 'c' policy is practically 'allow'-ish as we have lots of adhoc fallbacks to pure functions.

verify: always check rawsize Previously, verify only checks "rawsize == len(rawtext)", if "len(fl.read()) != fl.size()". With flag processor, "len(fl.read()) != fl.size()" does not necessarily mean "rawsize == len(rawtext)". So we may miss a useful check. This patch removes the "if len(fl.read()) != fl.size()" condition so the rawsize check is always performed. With the condition removed, "fl.read(n)" looks unnecessary so a comment was added to explain the side effect is wanted.

rebase: rename "target" to "destination" in messages The help text for rebase calls it "the destination" (never "target"), so let's use that in messages as well.

rebase: rename "target" to "dest" in variable names It took me a while to figure out that "target" was actually what's passed to --dest.