- Aug 01, 2018
-
-
durin42 authored
-
Boris Feld authored
Fix the descendant deprecated method introduced earlier in this cycle. This was caught by Yuya, thank you.
-
- Jul 31, 2018
-
-
Gregory Szorc authored
commands.status.terse=u can add significant overhead when operating on large repositories. Using the Firefox repository: HGRCPATH= hg --time status time: real 1.340 secs (user 0.960+0.000 sys 0.380+0.000) HGRCPATH= hg --time --config commands.status.terse=u status time: real 2.420 secs (user 2.070+0.000 sys 0.360+0.000) HGRCPATH= hg --time --config extensions.fsmonitor= status time: real 0.080 secs (user 0.050+0.010 sys 0.040+0.000) HGRCPATH= ~/src/hg/hg --time --config extensions.fsmonitor= --config commands.status.terse=u status time: real 2.470 secs (user 2.080+0.000 sys 0.390+0.000) The performance regression - especially when fsmonitor is being used - is too much to stomach for the 4.7 release. We've decided to remove commands.status.terse=u from ui.tweakdefaults until we can improve its performance, hopefully in the 4.8 cycle. This commit effectively backs out 6acf41bb8d40.
-
- Jul 25, 2018
-
-
Pulkit Goyal authored
Subversion can have a file as executable link. When using hgsubversion, we will have both islink and isexec True. This will lead to _flags being set to `lx`. However, manifest expects flag to be one-byte so it will crash if 'lx' is passed. Also it's impossible to have an executable link. This patch will safegaurd us from having 'lx' being a possible value. This was authored by Ivan Lezhankin from Yandex. Differential Revision: https://phab.mercurial-scm.org/D3985
-
- Jul 31, 2018
-
-
Boris Feld authored
This come as an extra security, better safe than sorry.
-
- Jul 30, 2018
-
-
Boris Feld authored
Sparse revlog rely on general delta, so we should make sure it is used.
-
- Jul 29, 2018
-
-
Yuya Nishihara authored
On Windows, EACCES is raised in place of EISDIR. This patch simply adds EACCES to the list of errors to be ignored since I think it's okay for filesets to treat inaccessible working-copy files as not existing.
-
- Jul 27, 2018
-
-
Pulkit Goyal authored
In merge, we do trivial resolution for files which were deleted on one side and changed on other. When sparse extension in involved that file might not be present in wdir and trivial resolution can lead to file not found error. This patch make sure we updates the sparse checkout before doing the trivial resolution. This fixes the test failure demonstrated in previous patch. Differential Revision: https://phab.mercurial-scm.org/D3984
-
Pulkit Goyal authored
This patch adds a test to demonstrate that `hg merge` is broken in some cases while using sparse extension. The case is when you have a file which is: * modified between current wdir parent and merge base * deleted between merge base and merge destination * excluded from sparse checkout Doing `hg merge` results in file not found error. Next patch will fix this. Differential Revision: https://phab.mercurial-scm.org/D3983
-
- Jul 30, 2018
-
-
Martin von Zweigbergk authored
I went a little too far in my cleanup in 9231148ea599 (context: convert to hex for error message only for 20-byte changeid, 2018-04-06). I missed that the case where a binary nodeid refers to a filtered node. Differential Revision: https://phab.mercurial-scm.org/D3987
-
- Jul 31, 2018
-
-
Boris Feld authored
This was an error in the initial commit. Thanks go to Marcel Svitalský for reporting the bug.
-
- Jul 30, 2018
-
-
Boris Feld authored
In theory, checkout is expected to be a node here because it was returned by peer.lookup. In practice, multiple important extensions (like hg-git, hg-subversion) use peers not backed by a mercurial repository where lookup cannot return a node. Allowing arbitrary symbols is necessary to make these extensions working with 4.7. We should probably introduce a new API in Core to have these extensions to work without abusing the lookup API. In the meantime, a small change to restore compatibility in 4.7 seems in order.
-
Augie Fackler authored
The sed invocation was failing on OS X and FreeBSD. I'm far too lazy to diagnose that, so just use some inline Python to fix the build.
-
Augie Fackler authored
This fixes mercurial/context.py:593: SyntaxError: cannot mix bytes and nonbytes literals (context.py, line 593) in Python 3.
-
- Jul 28, 2018
-
-
Yuya Nishihara authored
Otherwise it wouldn't be caught by a fast path of pathutil.canonpath(), and fall back to file identity checks.
-
- Jul 30, 2018
-
-
Yuya Nishihara authored
-
- Jul 28, 2018
-
-
Yuya Nishihara authored
I don't know if it is a feature or a bug, but it appears that environment variables passed to a shell function persist on /bin/sh.
-
Yuya Nishihara authored
It just worked by accident on some Linux sh.
-
- Jul 26, 2018
-
-
Gregory Szorc authored
error.tmpl wasn't consistent with other templates in gitweb in that it was missing a "graph" link. This commit makes it consistent.
-
- Jul 25, 2018
-
-
Cédric Krier authored
Differential Revision: https://phab.mercurial-scm.org/D3978
-
- Jul 20, 2018
-
-
Boris Feld authored
The idea was suggested by Gregory Szorc on IRC. It is more generic and seems better. It is probably best to rename the section before it ever makes into an official (non-rc) release. The only config option currently in this section have been prefixed with `revlog` to clarify it applies to `revlog` related storage.
-
- Jul 19, 2018
-
-
durin42 authored
-
durin42 authored
-
Gregory Szorc authored
913ca175c4ae broke BC by dropping support for reading format.aggressivemergedeltas. Let's restore it. Differential Revision: https://phab.mercurial-scm.org/D3966
-
Yuya Nishihara authored
-
Augie Fackler authored
-
Sushil Khanchi authored
Dropping this option because now we have a better option than passing --no-backup flag every time, now user can set a config in hgrc: [ui] history-editing-backup = False This config aims to operate on every history editing command and it is still work in progress. As yuya suggessted it probably to late to add full support this config, so making this as an experimental config. Differential Revision: https://phab.mercurial-scm.org/D3965
-
Boris Feld authored
The config does not follow our naming guideline and "Aggressive" is probably a word to keep away from users. The option does not truly fit in the `format` section. It can be turned on and off for existing repository without much consequence regarding compatibility. A new `revlog` option is created to control behavior related to revlog writing and reading. We can see multiple other config options that could be migrated there. * format.maxchainlen * experimental.mmapindexthreshold * experimental.sparse-read.density-threshold (in an updated form) * experimental.sparse-read.min-gap-size (in an updated form) In addition, we can foresee at least a couple of sparse-revlog related option coming too (to reduce delta chain length and increase snapshot reuse) These two extra options might fit there too. Unless we want to create a section dedicated to caches and performance. * format.chunkcachesize * format.manifestcachesize For now, we only migrate `optimize-delta-parent-choice` since it is getting out of experimental. It is too close to the release to move the other one. In addition, we still lack proper the prioritization of alias that would help renaming them without bad consequence for users. (Not fully happy about the `revlog` name but could not find better).
-
Boris Feld authored
The "aggressivemergedeltas" name is not great. First, it is quite long, second, we would rather have less "Aggressive" names within the project. We are about to rename the config option, so it seems the appropriate time to rename the internal variable.
-
Boris Feld authored
The config section now have a top level documentation to clarify its intend and usage. In particular, user are now explain when the option are taken in account and how to convert repository. There are an handful of experimental options in this section that does not match its definition. They should be relocated to other section before getting out of experimental. (see next changeset for one example).
-
Rodrigo Damazio Bovendorp authored
With the Python3 change, the string is now something like version = b'4.6.2+848-88be288e8ac1' where it was previously just: version = '4.6.2+848-88be288e8ac1' Differential Revision: https://phab.mercurial-scm.org/D3964
-
- Jul 10, 2018
-
-
Sushil Khanchi authored
Instead of passing --no-backup option every time you don't want to store backup, now you can set config option: [ui] history-editing-backup = False This option aims to operate on every history editing command. Differential Revision: https://phab.mercurial-scm.org/D3901
-
- Jul 18, 2018
-
-
Gregory Szorc authored
In default installs, this has the effect of disabling the thread-based worker on Windows when manifesting files in the working directory. My measurements have shown that with revlog-based repositories, Mercurial spends a lot of CPU time in revlog code resolving file data. This ends up incurring a lot of context switching across threads and slows down `hg update` operations when going from an empty working directory to the tip of the repo. On mozilla-unified (246,351 files) on an i7-6700K (4+4 CPUs): before: 487s wall after: 360s wall (equivalent to worker.enabled=false) cpus=2: 379s wall Even with only 2 threads, the thread pool is still slower. The introduction of the thread-based worker (02b36e860e0b) states that it resulted in a "~50%" speedup for `hg sparse --enable-profile` and `hg sparse --disable-profile`. This disagrees with my measurement above. I theorize a few reasons for this: 1) Removal of files from the working directory is I/O - not CPU - bound and should benefit from a thread pool (unless I/O is insanely fast and the GIL release is near instantaneous). So tests like `hg sparse --enable-profile` may exercise deletion throughput and aren't good benchmarks for worker tasks that are CPU heavy. 2) The patch was authored by someone at Facebook. The results were likely measured against a repository using remotefilelog. And I believe that revision retrieval during working directory updates with remotefilelog will often use a remote store, thus being I/O and not CPU bound. This probably resulted in an overstated performance gain. Since there appears to be a need to enable the thread-based worker with some stores, I've made the flagging of file gets as thread safe configurable. I've made it experimental because I don't want to formalize a boolean flag for this option and because this attribute is best captured against the store implementation. But we don't have a proper store API for this yet. I'd rather cross this bridge later. It is possible there are revlog-based repositories that do benefit from a thread-based worker. I didn't do very comprehensive testing. If there are, we may want to devise a more proper algorithm for whether to use the thread-based worker, including possibly config options to limit the number of threads to use. But until I see evidence that justifies complexity, simplicity wins. Differential Revision: https://phab.mercurial-scm.org/D3963
-
Gregory Szorc authored
The worker on Windows is implemented using a thread pool. If worker tasks are not thread safe, badness can occur. In addition, if tasks are executing CPU bound code and holding onto the GIL, there will be non-substantial overhead in Python context switching between active threads. This can result in significant slowdowns of tasks. This commit teaches the code for determining whether to use a worker to take thread safety into account. Effectively, thread unsafe tasks don't use the thread-based worker on Windows. Differential Revision: https://phab.mercurial-scm.org/D3962
-
- Jul 17, 2018
-
-
Gregory Szorc authored
Differential Revision: https://phab.mercurial-scm.org/D3961
-
Danny Hooper authored
This allows us to pass results larger than PIPE_BUF through the pipes without interleaving them. This is necessary now because "hg fix" sends file contents as the result from workers. Differential Revision: https://phab.mercurial-scm.org/D3960
-
- Jan 28, 2018
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D1945
-
- Jul 16, 2018
-
-
Boris Feld authored
Since b86664c81833, we process the `--debug` flag earlier. This is overall good and useful, but has at least one negative side effect. Previously the debug message we report when trying to import extensions were issued before we processed the `--debug` flag. Now they happen after. Before: $ ./hg id --debug 21f507b8de2f9c1606e9aeb5ec7d2a6dedb7a4a7 tip After: $ ./hg id --debug ☿ (revset-bench) could not import hgext.evolve (No module named evolve): trying hgext3rd.evolve could not import hgext.mercurial_keyring (No module named mercurial_keyring): trying hgext3rd.mercurial_keyring could not import hgext3rd.mercurial_keyring (No module named mercurial_keyring): trying mercurial_keyring could not import hgext.hggit (No module named hggit): trying hgext3rd.hggit could not import hgext3rd.hggit (No module named hggit): trying hggit 21f507b8de2f9c1606e9aeb5ec7d2a6dedb7a4a7 tip (This get worse if --traceback is used). To work around this, we move this extensions related debug message behind a new flag 'devel.debug.extensions' and restore the previous output. I'm not fully happy about using the 'devel' section for a flag that can be used by legitimate users to debug extensions issues. However, it fits well next to other `devel.devel.*` options and is mostly used by extensions author anyway. We might move it to another, more appropriate section in the future (using alias).
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D3948
-
Matt Harbison authored
It's convenient to be able to reference hooks in a portable location on any platform.
-