filelog: custom filelog to be used with narrow repos Narrow repos may have file revisions whose copy/rename metadata references files not in the store. This can pose problems when consumers attempt to access a missing referenced file revision. The narrow extension hacks around this problem by implementing a derived filelog type that provides custom implementations of renamed(), size(), and cmp() which handle renames against files not in the narrow spec by silently removing the rename metadata. While silently dropping metadata isn't the most robust solution, it is the easiest to implement. This commit ports the custom narrow filelog class to core. When a narrow repo is constructed, its ifilestorage creation function will automatically use the new filelog type. This means the extra logic is 0 cost for non-narrow repos and shouldn't interfere with their operation. Differential Revision: https://phab.mercurial-scm.org/D4643

localrepo: iteratively derive local repository type This commit implements the dynamic local repository type derivation that was explained in the recent commit bfeab472e3c0 "localrepo: create new function for instantiating a local repo object." Instead of a static localrepository class/type which must be customized after construction, we now dynamically construct a type by building up base classes/types to represent specific repository interfaces. Conceptually, the end state is similar to what was happening when various extensions would monkeypatch the __class__ of newly-constructed repo instances. However, the approach is inverted. Instead of making the instance then customizing it, we do the customization up front by influencing the behavior of the type then we instantiate that custom type. This approach gives us much more flexibility. For example, we can use completely separate classes for implementing different aspects of the repository. For example, we could have one class representing revlog-based file storage and another representing non-revlog based file storage. When then choose which implementation to use based on the presence of repo requirements. A concern with this approach is that it creates a lot more types and complexity and that complexity adds overhead. Yes, it is true that this approach will result in more types being created. Yes, this is more complicated than traditional "instantiate a static type." However, I believe the alternatives to supporting alternate storage backends are just as complicated. (Before I arrived at this solution, I had patches storing factory functions on local repo instances for e.g. constructing a file storage instance. We ended up having a handful of these. And this was logically identical to assigning custom methods. Since we were logically changing the type of the instance, I figured it would be better to just use specialized types instead of introducing levels of abstraction at run-time.) On the performance front, I don't believe that having N base classes has any significant performance overhead compared to just a single base class. Intuition says that Python will need to iterate the base classes to find an attribute. However, CPython caches method lookups: as long as the __class__ or MRO isn't changing, method attribute lookup should be constant time after first access. And non-method attributes are stored in __dict__, of which there is only 1 per object, so the number of base classes for __dict__ is irrelevant. Anyway, this commit splits up the monolithic completelocalrepository interface into sub-interfaces: 1 for file storage and 1 representing everything else. We've taught ``makelocalrepository()`` to call a series of factory functions which will produce types implementing specific interfaces. It then calls type() to create a new type from the built-up list of base types. This commit should be considered a start and not the end state. I suspect we'll hit a number of problems as we start to implement alternate storage backends: * Passing custom arguments to __init__ and setting custom attributes on __dict__. * Customizing the set of interfaces that are needed. e.g. the "readonly" intent could translate to not requesting an interface providing methods related to writing. * More ergonomic way for extensions to insert themselves so their callbacks aren't unconditionally called. * Wanting to modify vfs instances, other arguments passed to __init__. That being said, this code is usable in its current state and I'm convinced future commits will demonstrate the value in this approach. Differential Revision: https://phab.mercurial-scm.org/D4642

localrepo: pass root manifest into manifestlog.__init__ Today, localrepository has a method that can be overloaded which returns an instance of the root manifest storage object. When a manifestlog is created, it calls this private method and stores the root manifest object on it. This "hook" on localrepository isn't part of the documented interface. It isn't compatible with our desire to make repo storage determined before the repo object is constructed. This commit changes manifestlog.__init__ to accept the root storage object instead of calling into the repo to construct it. By doing things this way, the repo instance is responsible for constructing the manifest storage object directly. This does mean that other derived repo types need to overload manifestlog(). But they should have been doing this already, as manifestlog() is typically decorated in a storage-specific way. e.g. localrepository.manifestlog() is decorated as @storecache('00manifest.i'). And this assumes that a 00manifest.i file exists in the store vfs. This condition may not hold for repository types using non-revlog storage. So it is important for special repo types to override manifestlog() to remove this file association. The code changed in perf is wrong because it isn't compatible with older Mercurial versions. But I'm pretty sure the code was broken on older versions before this commit. It only affects `hg perftags`. I don't care enough to fix that at this time. .. api:: ``manifest.manifestlog.__init__()`` now receives the root manifest storage instance instead of calling into a private method on the repo object to obtain it. Differential Revision: https://phab.mercurial-scm.org/D4641

py3: create built in exceptions with str type messages in win32.py I hit an IOError in unlink() in test-pathconflicts-basic.t, that then crashed as it was handled: File "mercurial\dispatch.py", line 359, in _runcatch return _callcatch(ui, _runcatchfunc) File "mercurial\dispatch.py", line 367, in _callcatch return scmutil.callcatch(ui, func) File "mercurial\scmutil.py", line 252, in callcatch ui.error(_("abort: %s\n") % encoding.strtolocal(inst.strerror)) File "mercurial\encoding.py", line 205, in unitolocal return tolocal(u.encode('utf-8')) AttributeError: 'bytes' object has no attribute 'encode'

tests: stabilize test-shelve.t#phasebased for #no-symlink and #no-execbit The rev number ended up being 11 instead of 13 on Windows. If I ever get back to issue2020, this will go away.

debugdirstate: deprecate --nodates in favor of --no-dates We have supported 'no-' prefixes for boolean flag for a few years now, so I was expecting it to be --no-dates. I noticed that we have --nodates options for a few more commands (e.g. `hg diff`), but I'll leave that for another day. Differential Revision: https://phab.mercurial-scm.org/D4693

py3: fix a type error in hghave.has_hardlink test-hghave.t was failing with: feature hardlink failed: argument 1: <class 'TypeError'>: wrong type

narrow: remove hack to read narowspec from shared .hg directory This was another leftover from 576eef1ab43d (narrow: move .hg/narrowspec to .hg/store/narrowspec (BC), 2018-08-02), in addition to 623081f2abc2 (narrow: remove hack to write narrowspec to shared .hg directory, 2018-09-12). Differential Revision: https://phab.mercurial-scm.org/D4692

streamclone: reimplement nested context manager It's gone in Python 3, and you can't *ctxs into a with statement. Sigh. Differential Revision: https://phab.mercurial-scm.org/D4690

bundle2: grab kwarg using sysstr # skip-blame just an r prefix on a string Differential Revision: https://phab.mercurial-scm.org/D4691

py3: mark another passing test Differential Revision: https://phab.mercurial-scm.org/D4689

bookmarks: remove --active in favor of --list It's weird that we have both --active and --inactive options meaning completely different things. Instead of adding a one-off option, let's document the way to display the active bookmark by using -l/--list. No deprecated option is added since --active isn't released yet.

bookmarks: add explicit option to list bookmarks of the given names This is a generalized form of the --active option. A redundant sorted() call is removed. There was no point to update dict items in lexicographical order.

bookmarks: reject --delete with --inactive which makes no sense A deleted bookmark is neither active nor inactive.

bookmarks: parse out --inactive to action early The --inactive option can't be directly mapped to an action or a modifier. With any names, it means to add/rename to inactive bookmarks. Without names, it means to deactivate the current bookmark. This patch separates them to "inactive" flag and "action == 'inactive'".

bookmarks: parse out implicit "add" action early This prepares for adding -l/--list option, which can be combined with the positional arguments.

bookmarks: clarify that opts['rename'] points to an old bookmark to be renamed

bookmarks: refactor option checking to pick one from --delete/rename/active

bookmarks: convert opts to bytes dict early

bookmarks: pass in formatter to printbookmarks() instead of opts (API) This clarifies that user options have to be processed before calling printbookmarks().

strip: ignore orphaned internal changesets while computing safe strip roots Internal changeset can be safely garbage collected, so we can ignore them during safestrip. (Another phase for internal changeset that must be kept in the repository might be introduced later).

shelve: no longer strip internal commit when using internal phase When the internal phase is used, the internal commits we create during shelve will be automatically hidden, and we don't need to strip them. Avoiding strips gives much better performances and is less traumatic for caches. Test changes are all related to revision numbers increasing more quickly since we avoid stripping. At the end of `test-shelve.t` we now need manually strip the shelve-commit in addition to the x.shelve file deletion. This emulates a preexisting shelve after a repository upgrade. Note: The hidden internal commits confuses rebase a bit as shown by a new test added. This will happen when the user have shelve commits on top of a changeset to be rebased. We'll fix this in the next commit. As we still use a backup bundle, rebase can just strip the internal changesets and be fine.

meld: enable auto-merge This tells meld to resolve trivial conflicts before presenting the user with the remaining conflicts. This was attempted 5 years ago, but then --auto-merge was too new that the patch was rejected out of concern that users still had an older version of meld installed [1]. Maybe it's safe to assume that they have a newer version now. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2013-April/050084.html Differential Revision: https://phab.mercurial-scm.org/D4665

run-tests: partially backout PYTHON quoting In 7f8b7a060584, I quoted this to support python being installed to "Program Files". Even though the string passed to os.popen() is this: "c:/Python27/python.exe" -c "import mercurial; print (mercurial.__path__[0])" ... cmd.exe is trying to run this: 'c:/Python27/python.exe" -c "import' This caused test-hghave.t to fail, reporting 'unexpected mercurial lib: ""', because the failed execution prints nothing to stdout. Py3 fails as though it's not quoted. For whatever reason, print() shows up in the output when run with py2, but not py3, so I'm having a hard time debugging this. For now, let's fix the buildbot.

py3: use '%d' instead of '%s' for integers Python 3 does not allow to use '%s' for integers. Differential Revision: https://phab.mercurial-scm.org/D4688

py3: use print as a function in tests/test-revert.t This makes the test work on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4687

chgserver: restore pager fds attached within runcommand session While rewriting chg in Rust, I noticed the server leaks the client's pager fd. This isn't a problem right now since the IPC process terminates earlier than the pager, but I believe the fds attached within a "runcommand" request should be released as soon as the session ends.

chgserver: add separate flag to remember if stdio fds are replaced I want to make it use a separate saved buffer for "attachio" requests within "runcommand" session. See the next patch for details.