Tue, 26 Mar 2019 14:02:40 +0100 debugdiscovery: allow to select random seed during debugdiscovery run
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2019 14:02:40 +0100] rev 42030
debugdiscovery: allow to select random seed during debugdiscovery run The randomness can lead to large timing difference, controling it is important.
Sun, 17 Mar 2019 18:45:53 +0300 discovery: move cl.hasnode outside of the for-loop
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:45:53 +0300] rev 42029
discovery: move cl.hasnode outside of the for-loop IIUC, resolving attributes for changelog can lead to some overhead. So this patch moves that to outside of a for-loop. Differential Revision: https://phab.mercurial-scm.org/D6147
Sun, 17 Mar 2019 18:43:27 +0300 discovery: prevent deleting items from a dictionary
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:43:27 +0300] rev 42028
discovery: prevent deleting items from a dictionary Removing elements from Python dictionary is expensive. So let's prevent adding them instead. I added a newline to make code look a bit better. Differential Revision: https://phab.mercurial-scm.org/D6146
Sun, 17 Mar 2019 18:34:28 +0300 discovery: drop some unused sets
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:34:28 +0300] rev 42027
discovery: drop some unused sets Differential Revision: https://phab.mercurial-scm.org/D6145
Sun, 17 Mar 2019 18:29:23 +0300 discovery: prevent recomputing info about server and outgoing changesets
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 17 Mar 2019 18:29:23 +0300] rev 42026
discovery: prevent recomputing info about server and outgoing changesets We already iterate over the outgoing.missing above and lookup repo for them. So let's reuse info calculated at that time instead of recomputing that again. Also we calculate the set of remotebranches by doing set(remotemap), so let's reuse that again. Upcoming patches will clean things a bit more. Differential Revision: https://phab.mercurial-scm.org/D6144
Thu, 21 Mar 2019 21:44:29 +0100 crecord: draw on the whole screen
Alexander Kobjolke <alex@jakalx.net> [Thu, 21 Mar 2019 21:44:29 +0100] rev 42025
crecord: draw on the whole screen When starting crecord, one can see that it has a small gap on the rightmost column which doesn't get used. This is in contrast to other interactive curses frontends such as chistedit. Disabling the displaying of the cursor allows drawing on the whole availabe area and thus some hacky code in align() could be removed. Differential Revision: https://phab.mercurial-scm.org/D6171
Fri, 15 Mar 2019 11:24:08 -0700 automation: perform tasks on remote machines
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 15 Mar 2019 11:24:08 -0700] rev 42024
automation: perform tasks on remote machines Sometimes you don't have access to a machine in order to do something. For example, you may not have access to a Windows machine required to build Windows binaries or run tests on that platform. This commit introduces a pile of code intended to help "automate" common tasks, like building release artifacts. In its current form, the automation code provides functionality for performing tasks on Windows EC2 instances. The hgautomation.aws module provides functionality for integrating with AWS. It manages EC2 resources such as IAM roles, EC2 security groups, AMIs, and instances. The hgautomation.windows module provides a higher-level interface for performing tasks on remote Windows machines. The hgautomation.cli module provides a command-line interface to these higher-level primitives. I attempted to structure Windows remote machine interaction around Windows Remoting / PowerShell. This is kinda/sorta like SSH + shell, but for Windows. In theory, most of the functionality is cloud provider agnostic, as we should be able to use any established WinRM connection to interact with a remote. In reality, we're tightly coupled to AWS at the moment because I didn't want to prematurely add abstractions for a 2nd cloud provider. (1 was hard enough to implement.) In the aws module is code for creating an image with a fully functional Mercurial development environment. It contains VC9, VC2017, msys, and other dependencies. The image is fully capable of building all the existing Mercurial release artifacts and running tests. There are a few things that don't work. For example, running Windows tests with Python 3. But building the Windows release artifacts does work. And that was an impetus for this work. (Although we don't yet support code signing.) Getting this functionality to work was extremely time consuming. It took hours debugging permissions failures and other wonky behavior due to PowerShell Remoting. (The permissions model for PowerShell is crazy and you brush up against all kinds of issues because of the user/privileges of the user running the PowerShell and the permissions of the PowerShell session itself.) The functionality around AWS resource management could use some improving. In theory we support shared tenancy via resource name prefixing. In reality, we don't offer a way to configure this. Speaking of AWS resource management, I thought about using a tool like Terraform to manage resources. But at our scale, writing a few dozen lines of code to manage resources seemed acceptable. Maybe we should reconsider this if things grow out of control. Time will tell. Currently, emphasis is placed on Windows. But I only started there because it was likely to be the most difficult to implement. It should be relatively trivial to automate tasks on remote Linux machines. In fact, I have a ~1 year old script to run tests on a remote EC2 instance. I will likely be porting that to this new "framework" in the near future. # no-check-commit because foo_bar functions Differential Revision: https://phab.mercurial-scm.org/D6142
Sat, 09 Mar 2019 16:36:08 -0800 contrib: PowerShell script to install development dependencies
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 09 Mar 2019 16:36:08 -0800] rev 42023
contrib: PowerShell script to install development dependencies Configuring a Windows machine to hack on Mercurial is a bit of work and it isn't documented very well. This commit introduces a PowerShell script to automate going from a fresh Windows install to an environment suitable for building Mercurial, its installers, and running tests. Differential Revision: https://phab.mercurial-scm.org/D6141
Tue, 26 Mar 2019 11:53:30 -0400 chistedit: change in-progress message
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 26 Mar 2019 11:53:30 -0400] rev 42022
chistedit: change in-progress message Saying "running histedit" is an artifact of when chistedit was a separate thing from histedit. I found the message a bit confusing, since wasn't I running histedit from the beginning, just from the curses interface? The whole thing is now histedit, both the curses interface and the underlying procedure to apply a plan, so let's use a message that doesn't make a distinction.
Tue, 26 Mar 2019 10:21:17 -0400 perf: copyedit a few documentation strings
Augie Fackler <augie@google.com> [Tue, 26 Mar 2019 10:21:17 -0400] rev 42021
perf: copyedit a few documentation strings Differential Revision: https://phab.mercurial-scm.org/D6170
Sun, 24 Mar 2019 20:13:13 -0400 shelve: add --keep to list of allowables
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Sun, 24 Mar 2019 20:13:13 -0400] rev 42020
shelve: add --keep to list of allowables
Sun, 17 Mar 2019 12:30:52 +0000 perf: introduce a `perf.run-limits` options
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Mar 2019 12:30:52 +0000] rev 42019
perf: introduce a `perf.run-limits` options This options make it possible to configure the number of run that the extensions will perform. This is useful for automated benchmark or for performance measurement that need better accuracy.
Sat, 16 Mar 2019 19:11:19 +0000 perf: pass limits as a function argument
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Mar 2019 19:11:19 +0000] rev 42018
perf: pass limits as a function argument The function applying the limit has no access to the configuration. Therefore, some higher layer will have to pass it as argument. We do this in an independent change to clarify the next change.
Sat, 16 Mar 2019 19:08:27 +0000 perf: more flexible implementation for checking stop conditions
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Mar 2019 19:08:27 +0000] rev 42017
perf: more flexible implementation for checking stop conditions We want to make this logic simpler to configure. The first step is to stop hard-coding every values.
Mon, 25 Mar 2019 08:41:02 -0700 perf: document perfparents
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 08:41:02 -0700] rev 42016
perf: document perfparents
Mon, 25 Mar 2019 13:43:40 +0100 perf: document config options
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 13:43:40 +0100] rev 42015
perf: document config options We have configuration, so we better document it.
Mon, 25 Mar 2019 13:16:53 +0100 tests: use "perf" as a the extension name in test-contrib-perf.t
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2019 13:16:53 +0100] rev 42014
tests: use "perf" as a the extension name in test-contrib-perf.t This is simpler and seems more "inline" with the name people usually use for this extensions.
Fri, 22 Mar 2019 11:26:47 -0400 shelve: do not update when keeping changes, just move the dirstate
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 11:26:47 -0400] rev 42013
shelve: do not update when keeping changes, just move the dirstate This is to leave the working directory unchanged. We reuse the match object as an optimisation.
Fri, 22 Mar 2019 13:03:26 -0400 shelve: refactor _shelvecreatedcommit's match object into calling site
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 13:03:26 -0400] rev 42012
shelve: refactor _shelvecreatedcommit's match object into calling site We might need to use this match object again to move the dirstate in case the user requested to `--keep` the changes.
Fri, 22 Mar 2019 11:24:23 -0400 shelve: new keep option
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 22 Mar 2019 11:24:23 -0400] rev 42011
shelve: new keep option Does nothing yet. The docstring describes what it will soon be doing.
Thu, 21 Mar 2019 21:40:22 -0400 diff: support diffing explicit files in subrepos
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Mar 2019 21:40:22 -0400] rev 42010
diff: support diffing explicit files in subrepos Most other commands support implied recursion based on file names already.
Thu, 21 Mar 2019 18:27:09 -0700 fix: make the order of the work queue deterministic
Danny Hooper <hooper@google.com> [Thu, 21 Mar 2019 18:27:09 -0700] rev 42009
fix: make the order of the work queue deterministic This makes any output generated during the parallel phase of execution stable if parallelism is disabled. This helps write tests like that in the future. Differential Revision: https://phab.mercurial-scm.org/D6166
Thu, 21 Mar 2019 18:35:39 -0700 fix: allow fixing untracked files when given as arguments
Danny Hooper <hooper@google.com> [Thu, 21 Mar 2019 18:35:39 -0700] rev 42008
fix: allow fixing untracked files when given as arguments It's more useful to fix the file than to silently avoid it when the user does this: hg fix --working-dir untracked-file We will still do nothing to ignored files, even if they are specified. This may be safer, given that such files can unexpectedly slip into the arguments via a shell glob or fileset. Differential Revision: https://phab.mercurial-scm.org/D6165
Tue, 19 Mar 2019 16:26:52 +0300 branchcache: have a hasnode function to validate nodes
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:26:52 +0300] rev 42007
branchcache: have a hasnode function to validate nodes Upcoming patches will delay node validation until it's required. So we need to a way in branchcache class to check whether a node exists or node. Other options were making repo or changelog an attribute of branchcache object. But the branchcache depends on filters so I decided to pass a function object. Differential Revision: https://phab.mercurial-scm.org/D6157
Tue, 19 Mar 2019 16:20:02 +0300 branchcache: add attributes to track which nodes are verified
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:20:02 +0300] rev 42006
branchcache: add attributes to track which nodes are verified Half of the cost of loading branchcache comes from verifiying all the nodes it has. We don't need to verify all the nodes in all the cases. Sometimes we need to verify only a set of nodes for a set of branches. We can ignore nodes of other branches as we are not going to read them. This patch introduces two attributes to branchcache class. _verifiedbranches is a set which will tell the branches for which it's head nodes are verified. _closedverified is a boolean which will tell whether all closednodes are verified or not. Another idea which I had was to keep a set of nodes which are verified, but it will be more ugly and difficult to track things on node level. Differential Revision: https://phab.mercurial-scm.org/D6156
Mon, 18 Mar 2019 19:44:55 +0300 branchcache: make entries a private attribute
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:44:55 +0300] rev 42005
branchcache: make entries a private attribute Differential Revision: https://phab.mercurial-scm.org/D6155
Mon, 18 Mar 2019 19:31:45 +0300 branchcache: introduce hasbranch()
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:31:45 +0300] rev 42004
branchcache: introduce hasbranch() This will be used to check whether a branch exists or not. This will optimized in future. Differential Revision: https://phab.mercurial-scm.org/D6154
Mon, 18 Mar 2019 19:11:55 +0300 branchmap: drop branchcache.setdefault() (API)
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:11:55 +0300] rev 42003
branchmap: drop branchcache.setdefault() (API) All the callers are updated to call setdefault of branchcache.entries Differential Revision: https://phab.mercurial-scm.org/D6153
Mon, 18 Mar 2019 19:01:29 +0300 branchcache: rename itervalues() to iterheads()
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 19:01:29 +0300] rev 42002
branchcache: rename itervalues() to iterheads() The itervalues() exists because branchcache() had a dict interface. Since it no longer has a dict interface, it makes sense to have better function names. If a person does not understand how branchcache stores info, it will be hard for them to guess what itervalues() does. Differential Revision: https://phab.mercurial-scm.org/D6152
Mon, 18 Mar 2019 18:59:38 +0300 branchmap: remove the dict interface from the branchcache class (API)
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 18:59:38 +0300] rev 42001
branchmap: remove the dict interface from the branchcache class (API) The current branchmap computation involves reading the whole branchmap from disk, validating all the nodes even if they are not required. This leads to a lot of time on repos which have large branchmap or a lot of branches. On large repos, this can validate around 1000's of nodes. On some operations, like finding whether a branch exists or not, we don't need to validate all the nodes. Or updating heads for a single branch. Before this patch, branchcache class was having dict interface and it was hard to keep track of reads. This patch removes the dict interface. Upcoming patches will implement lazy loading and validation of data and implement better API's. Differential Revision: https://phab.mercurial-scm.org/D6151
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip