Thu, 06 Jul 2017 14:53:48 +0200 effectflag: detect when user changed
Boris Feld <boris.feld@octobus.net> [Thu, 06 Jul 2017 14:53:48 +0200] rev 34416
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
Thu, 06 Jul 2017 14:52:34 +0200 effectflag: detect when description changed
Boris Feld <boris.feld@octobus.net> [Thu, 06 Jul 2017 14:52:34 +0200] rev 34415
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
Thu, 06 Jul 2017 14:51:08 +0200 tests: add tests for effect flags
Boris Feld <boris.feld@octobus.net> [Thu, 06 Jul 2017 14:51:08 +0200] rev 34414
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
Thu, 06 Jul 2017 14:50:17 +0200 effectflag: store an empty effect flag for the moment
Boris Feld <boris.feld@octobus.net> [Thu, 06 Jul 2017 14:50:17 +0200] rev 34413
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
Fri, 30 Jun 2017 03:44:00 +0200 configitems: register the 'profiling.type' config
Boris Feld <boris.feld@octobus.net> [Fri, 30 Jun 2017 03:44:00 +0200] rev 34412
configitems: register the 'profiling.type' config
Fri, 30 Jun 2017 03:43:57 +0200 configitems: register the 'profiling.showmin' config
Boris Feld <boris.feld@octobus.net> [Fri, 30 Jun 2017 03:43:57 +0200] rev 34411
configitems: register the 'profiling.showmin' config
Fri, 30 Jun 2017 03:43:56 +0200 configitems: register the 'profiling.showmax' config
Boris Feld <boris.feld@octobus.net> [Fri, 30 Jun 2017 03:43:56 +0200] rev 34410
configitems: register the 'profiling.showmax' config
Fri, 30 Jun 2017 03:43:55 +0200 configitems: register the 'profiling.output' config
Boris Feld <boris.feld@octobus.net> [Fri, 30 Jun 2017 03:43:55 +0200] rev 34409
configitems: register the 'profiling.output' config
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip