Added tag 5.8.1 for changeset 411dc27fd9fd

corruption: backout changeset 49fd21f32695 (issue6528) inverting the parent is masking copy information leading to bad content being fetched and bad status result. Since 49fd21f32695, exchange can actively swap these parent corrupting existing changesets and triggering the corruption. Data corruption are considered critical so backing this out and doing and unscheduled release seems in order. Differential Revision: https://phab.mercurial-scm.org/D10995

corruption: add a test for issue6528 The initial reproduction script was provided by Charles Chamberlain from Jane Street. Differential Revision: https://phab.mercurial-scm.org/D10996

stream: double check that self.vfs is *not* in the vfsmap The stream clone logic allows for writing any content to any file under various vfs. This is *not* suitable for *vfs*, since writing in `.hg/` directly allow to modify the configuration and is a great and simple gateway for remote code execution. Differential Revision: https://phab.mercurial-scm.org/D10905

Backed out changeset 9b8f326731ac Unfortunately, disabling the rust extensions means newer Mercurial versions no longer have the persistent-nodemap feature enabled. This means a Mercurial 5.8.1 on RPM-based Linux distributions will no longer be able to read repositories created by a Mercurial 5.8 on RPM-based Linux distributions. This violates the compatibility rules (see https://www.mercurial-scm.org/wiki/CompatibilityRules ). For this reason, I have to backout this change. I'll try to find another solution to the 'hg purge' crashes. Differential Revision: https://phab.mercurial-scm.org/D10918

packaging: disable rust extensions again on CentOS Backed out changeset eccbfa7e19c0 We're seeing (very rarely) crashes of 'hg purge' on some of our machines (see https://bz.mercurial-scm.org/show_bug.cgi?id=6509 ). Unfortunately, I haven't been able to find out much more about what is going wrong. To avoid further impact on our users and CI, I would prefer to disable the rust extensions for now. Differential Revision: https://phab.mercurial-scm.org/D10877

cext: fix memory leak in phases computation Without this a buffer whose size in bytes is the number of changesets in the repository is leaked each time the repository is opened and changeset phases are computed. Impact: the current code in hgwebdir creates a new `localrepository` instance for each HTTP request. Since any pull or push is made of several requests, a team of 100 people can easily produce thousands of such requests per day. Being a low-level malloc, this leak can't be seen with the gc module and tools relying on that, but was spotted by valgrind immediately. Reproduction ------------ for i in range(cl_args.iterations): repo = hg.repository(baseui, repo_path) rev = repo.revs(rev).first() ctx = repo[rev] del ctx del repo # avoid any pollution by other type of leak # (that should be fixed in 5.8) repoview._filteredrepotypes.clear() gc.collect() Measurements ------------ Resident Set Size (RSS), taken on a clone of mozilla-central for performance analysis (440 000 changesets). before: 5.8+hg19.5ac0f2a8ba72 1000 iterations: 1606MB 5.8+hg19.5ac0f2a8ba72 10000 iterations: 5723MB after: 5.8+hg20.e2084d39e145 1000 iterations: 555MB 5.8+hg20.e2084d39e145 10000 iterations: 555MB (double checked, not a copy/paste error) (e2084d39e14 is the present changeset, before amendment of the message to add the measurements)