relnotes/5.9

revlog: use the user facing filename as the display_id for filelogs

I had trouble isolating some LFS blob corruption detected by `hg verify` because
the traceback referenced a file, but with the `data/` prefix in the `.hg/store`
path, so it couldn't be located with the `file()` revset:

```
    Traceback (most recent call last):
      File "/mnt/d/mercurial/mercurial/revlog.py", line 3209, in verifyintegrity
        _verify_revision(self, skipflags, state, node)
      File "/mnt/d/mercurial/hgext/lfs/wrapper.py", line 246, in _verify_revision
        orig(rl, skipflags, state, node)
      File "/mnt/d/mercurial/mercurial/revlog.py", line 158, in _verify_revision
        rl.revision(node)
      File "/mnt/d/mercurial/mercurial/revlog.py", line 1816, in revision
        return self._revisiondata(nodeorrev, _df)
      File "/mnt/d/mercurial/mercurial/revlog.py", line 1870, in _revisiondata
        self.checkhash(text, node, rev=rev)
      File "/mnt/d/mercurial/mercurial/revlog.py", line 1996, in checkhash
        % (self.display_id, pycompat.bytestr(revornode))
    mercurial.error.RevlogError: integrity check failed on data/EXE/PPC/shrinksrec.exe:0
```

(I'm a little surprised it resulted in a stacktrace instead of just a message,
but that's a different issue.  I'm also not sure how to trigger the simplestore
case, since IIUC, it's also a revlog based store.)

It's not clear how to handle the changelog and manifest (because the user
doesn't interact with them as a file), so those cases are left alone.  The other
thing that would be nice to improve somehow is to indicate that the ":0" is a
revlog revision, not the changeset revision that users are used to.  I'm not
sure how to handle the "or node" part though.

== New Features ==

 * `hg config` now has a `--source` option to show where each
   configuration value comes from.
 * Introduced a command (debug-repair-issue6528) to repair repositories affected
   by issue6528 where certain files would show up as modified even if they were
   clean due to an issue in the copy-tracing code.

== Default Format Change ==

These changes affect newly created repositories (or new clone) done with
Mercurial 5.9.


== New Experimental Features ==

 * A `changelogv2` format has been introduced. It is not ready for use yet, but
   will be used later to address some of the weaknesses of the current revlog
   format.
 * Initial experiment and support for `dirstatev2`, a new dirstate format that
   addresses some of the weaknesses of the current dirstate format. Python + C
   and Rust support are being implemented, but the Rust solution is the one
   currently getting the attention for performance.
 * Initial support for `rhg status`. `rhg` is the Rust wrapper executable for hg
   that shortcuts some commands for faster execution speed.

== Bug Fixes ==

 * Fixed committing empty files with `narrow`
 * Allow overriding `pip`'s pep517 compliance to build C or Rust extensions
 * Fixed regression on outgoing email when not specifying revisions
 * Fixed a regression causing bookmarks to disappear when using Rust persistent nodemap
 * Fixed a regression (in 5.9.1) introduced in 5.9 when cloning repos with
   deep filenames
 * Fixed detection of directories becoming symlinks, but only when using the
   Rust extensions.
 * Fixed ignore and include not composing in the Rust status
 * `hg commit --interactive` now handles deselecting edits of a rename
 * Fixed a case where `hg evolve` gives different results when interrupted
 * Fixed a memory leak in phases computation
 * `histedit` and `shelve` don't swallow errors when updating the working copy
   anymore
 * Improve error message when detecting content-divergence with a hidden
   common predecessor
 * No longer re-order parents in filelog, see issue6533
 * Fix revisions affected by issue6533 on the fly during exchange
 * Many Windows fixes for stability and py3 compatibility improvements
 * Many other miscellaneous fixes

== Backwards Compatibility Changes ==


== Internal API Changes ==

The Dirstate API have been updated as the previous function leaked some
internal details and did not distinguish between two important cases: "We are
changing parent and need to adjust the dirstate" and "some command is changing
which file is tracked". To clarify the situation:

* the following functions have been deprecated,

  - `dirstate.add`,
  - `dirstate.normal`,
  - `dirstate.normallookup`,
  - `dirstate.merge`,
  - `dirstate.otherparent`,
  - `dirstate.remove`,
  - `dirstate.drop`,
  - `dirstateitem.__getitem__`,

* these new functions are added for the "adjusting parents" use-case:

  - `dirstate.update_file`,
  - `dirstate.update_file_p1`,

* these new function are added for the "adjusting wc file" use-case":

  - `dirstate.set_tracked`,
  - `dirstate.set_untracked`,
  - `dirstate.set_clean`,
  - `dirstate.set_possibly_dirty`,

See inline documentation of the new functions for details.

* Additionally, the following have been deprecated:
  - `urlutil.getpath` function
  - `localrepository.updatecaches`' `full` argument

* The following have been removed:
  - `revlog.revlogio` has been removed