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

commands: rename clone --uncompressed to --stream and document --uncompressed isn't a very good name and its description in the help documentation isn't very useful. We refer to this concept as "stream clones" in a number of places. I think it makes sense to change the user-facing argument to use the mode --stream. So this commit does that. We keep --uncompressed around for backwards compatibility. While we're here, we overhaul the help docs for streaming clones to be somewhat useful. All tests have been updated to reflect the new preferred --stream argument. A test for backwards compatibility of --uncompressed has been added. .. bc:: `hg clone --stream` should now be used instead of --uncompressed. --uncompressed is marked as deprecated and is an alias for --stream. There is no schedule for elimination of --uncompressed. Differential Revision: https://phab.mercurial-scm.org/D864

commands: remove suggestion to clone via `cp -al` This was added in 2df98f616645 in 2006. This may be possible but it seems like a bad idea to even suggest it. Differential Revision: https://phab.mercurial-scm.org/D863