docker: try to follow the best practices for writing Dockerfiles Merged multiple RUN instructions and sorted the arguments alphabetically Reference: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/

effectflag: document effect flag Differential Revision: https://phab.mercurial-scm.org/D542

effectflag: detect when diff changed Store in effect flag when the diff changed between the predecessor and its successors. Comparing the diff is not easy because we do not want to incorrectly detect a

effectflag: detect when meta changed Store in effect flag when the meta changed between the predecessor and its successors. We blacklisted some known meta that would always changed when another flag change. For example rebase would always add a meta rebase-source while the effect flag parents will already detect this situation. It can happens with various hg commands. Differential Revision: https://phab.mercurial-scm.org/D540

effectflag: detect when parents changed Store in effect flag when the parents changed between the predecessor and its successors. It can happens with "hg rebase" or "hg grab". Differential Revision: https://phab.mercurial-scm.org/D539

effectflag: detect when branch changed Store in effect flag when the branch changed between the predecessor and its successors. It can happens with "hg branch" + "hg commit --amend", "hg branch" + "hg amend" or "histedit". Differential Revision: https://phab.mercurial-scm.org/D538

effectflag: detect when date changed Store in effect flag when the date changed between the predecessor and its successors. It can happens with "hg commit --amend -d", "hg amend -d" or "histedit". Differential Revision: https://phab.mercurial-scm.org/D537

effectflag: detect when user changed Store in effect flag when the user changed between the predecessor and its successors. It can happens with "hg commit --amend -u" or "histedit". Differential Revision: https://phab.mercurial-scm.org/D536

effectflag: detect when description changed Store in effect flag when the description changed between the predecessor and its successors. It can happens with "hg commit --amend -e", "hg amend -e" or "histedit". Differential Revision: https://phab.mercurial-scm.org/D535

tests: add tests for effect flags Add all the tests in this patch, it makes the patch quite big but will clarify the following patches impact on tests. Differential Revision: https://phab.mercurial-scm.org/D534

effectflag: store an empty effect flag for the moment The idea behind effect flag is to store additional information in obs-markers about what changed between a changeset and its successor(s). It's a low-level information that comes without guarantees. This information can be computed a posteriori, but only if we have all changesets locally. This is not the case with distributed workflows where you work with several people or on several computers (eg: laptop + build server). Storing the effect-flag as a bitfield has several advantages: - It's compact, we are using one byte per obs-marker at most for the effect- flag. - It's compoundable, the obsfate log approach needs to display evolve history that could spans several obs-markers. Computing the effect-flag between a changeset and its grand-grand-grand-successor is simple thanks to the bitfield. The effect-flag design has also some limitations: - Evolving a changeset and reverting these changes just after would lead to two obs-markers with the same effect-flag without information that the first and third changesets are the same. The effect-flag current design is a trade-off between compactness and usefulness. Storing this information helps commands to display a more complete and understandable evolve history. For example, obslog (an Evolve command) use it to improve its output: x 62206adfd571 (34302) obscache: skip updating outdated obscache... | rewritten(parent) by Matthieu Laneuville <matthieu.laneuville@octobus... | rewritten(content) by Boris Feld <boris.feld@octobus.net> The effect flag is stored in obs-markers metadata while we iterate on the information we want to store. We plan to extend the existing obsmarkers bit-field when the effect flag design will be stabilized. It's different from the CommitCustody concept, effect-flag are not signed and can be forged. It's also different from the operation metadata as the command name (for example: amend) could alter a changeset in different ways (changing the content with hg amend, changing the description with hg amend -e, changing the user with hg amend -U). Also it's compatible with every custom command that writes obs-markers without needing to be updated. The effect-flag is placed behind an experimental flag set to off by default. Hook the saving of effect flag in create markers, but store only an empty one for the moment, I will refine the values in effect flag in following patches. For more information, see: https://www.mercurial-scm.org/wiki/ChangesetEvolutionDevel#Record_types_of_operation Differential Revision: https://phab.mercurial-scm.org/D533

configitems: register the 'profiling.type' config

configitems: register the 'profiling.showmin' config

configitems: register the 'profiling.showmax' config

configitems: register the 'profiling.output' config

dirstate: implement __len__ on dirstatemap (issue5695) Differential Revision: https://phab.mercurial-scm.org/D884

obsmarker: crash more helpfully when metadata fields are >255bytes (issue5681) Various mutators fail when attempting to write obsmarkers with metadata fields longer than 255 bytes, since the length of mwetadata fields is stored in u8s. This change raises a more helpful error in such circumstances. Differential Revision: https://phab.mercurial-scm.org/D865

deb: build and install chg Differential Revision: https://phab.mercurial-scm.org/D883

deb: install zsh completions to /usr/share/zsh/vendor-completions This location is used by debian (and ubuntu) to store completions provided by other deb packages. The default fpath appears to have this before any of the zsh-provided instances of the completions, so this should take precedence. Differential Revision: https://phab.mercurial-scm.org/D882

releasenotes: display release notes when no filename is specified If the filename is not specified while using --rev, the notes for the specified revs will just be displayed on screen. Differential Revision: https://phab.mercurial-scm.org/D877

hgweb: use parsebool for parsing diff query string options Differential Revision: https://phab.mercurial-scm.org/D875

hgweb: remove extra </div> This was accidentally added in 6797f1fbc642. Differential Revision: https://phab.mercurial-scm.org/D880

tests: add "have" check for dpkg builddeps Differential Revision: https://phab.mercurial-scm.org/D879

tests: expect parsers.so in cext, parsers.py in pure (test-debian-packages) Differential Revision: https://phab.mercurial-scm.org/D878

hghave: check for debuild being installed as well Differential Revision: https://phab.mercurial-scm.org/D874

changelog: use attrs instead of namedtuple See http://www.attrs.org/en/stable/why.html#namedtuples for why attrs are better than namedtuples. Differential Revision: https://phab.mercurial-scm.org/D868

thirdparty: vendor attrs The attrs package allows defining namedtuple-like classes with no weird behavior and no runtime performance cost. This patch vendors in attrs 17.2.0. # no-check-commit Differential Revision: https://phab.mercurial-scm.org/D867

python3: don't byte mangle third-party packages Third-party packages are already expected to be dual-version clean. Differential Revision: https://phab.mercurial-scm.org/D871

tests: disable lints on mercurial/thirdparty In the next patch, this directory will be used to vendor in some third-party code. Differential Revision: https://phab.mercurial-scm.org/D866

hghave: fix dpkg --version check to work on recent dpkg versions Differential Revision: https://phab.mercurial-scm.org/D869