httppasswordmgrdbproxy: specify exact arguments We only ever call these functions in a single way, so let's just actually specify them. We need to do some string/bytes encoding dancing here for Python 3, so it'll help to know what arguments we need to convert. # no-check-commit because I'm modifying functions that check-commit does not like. Differential Revision: https://phab.mercurial-scm.org/D885

formatter: fix default list/dict generator to be evaluated more than once Before, _hybrid.gen must be a generator which could be consumed only once. It was okay in templatekw.py since template keywords are functions which create temporary hybrid objects, but the formatter doesn't work in that way. To work around the issue, this patch makes _hybrid.gen optionally be a function returning a generator. Thanks to Pulkit for finding this issue.

doctest: drop hack to run py2/3 tests selectively All doctests pass on Python 3.

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