- Jan 15, 2021
-
-
Jörg Sonnenberger authored
Historically, the revision to branch mapping cache was updated on demand and shared via bundle2 to avoid the cost of rebuilding on first use. Use the new `register_changeset` callback and update rbc directly on every change. Make the transfer of the bundle part redundant, but keep it for the moment to avoid the test churn. Over all, "hg unbundle" for large bundles is less than 1.8% slower for different larger repositories and that seems to a reasonable trade off. Differential Revision: https://phab.mercurial-scm.org/D9781
-
- Jan 18, 2021
-
-
Jörg Sonnenberger authored
The new callback is called whenever a changeset is added to the repository (commit, unbundle or exchange). Since the bulk operations already parse the changeset (readfiles or full changesetrevision), always use the latter to avoid redundant lookups. The first consumer of the new interface needs to look at extra. Differential Revision: https://phab.mercurial-scm.org/D9780
-
- Jan 15, 2021
-
-
Jörg Sonnenberger authored
The function parses the extra dictionary after looking up the changelogrevision. To avoid duplicated look up, it is better to provide it as property of changelogrevision instead. Keep the function for a release cycle as at least the topic extension depends on it. Differential Revision: https://phab.mercurial-scm.org/D9779
-
- Jan 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
As discussed on D9671#146704 this lowers the error to a warning. Differential Revision: https://phab.mercurial-scm.org/D9852
-
- Jan 18, 2021
-
-
sliquister authored
The motivation is simple: it's nicer to avoid gating basic functionality. To reduce the risk of people shooting themselves in the feet, `--confirm` is now the default, unless the extensions is loaded.. For review of the body of the purge command, use this instead of what hg/phabricator will show (the block of code is modified, not just moved): Differential Revision: https://phab.mercurial-scm.org/D9820
-
Pierre-Yves David authored
Getting the exact number is simple (you have to project the result of previous deletion to detect super-directory with only about-to-be-deleted content). So we use a vaguer message. Differential Revision: https://phab.mercurial-scm.org/D9819
-
Pierre-Yves David authored
The options provide a prompt to the user before permanent deletion are made. The prompt is currently not aware of directory deletion. I'll fix this in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D9818
-
- May 11, 2020
-
-
Augie Fackler authored
This is a version of merge3 that always reports success, so that conflict markers get preserved without us having to implement conflict storage for in-memory merge. Credit to martinvonz for the idea. The only planned consumer of this "merge tool" is my upcoming merge-diffs functionality, though I suspect it could be useful in other ways. Differential Revision: https://phab.mercurial-scm.org/D8515
-
- May 28, 2020
-
-
Augie Fackler authored
Use it in a test case where we know the rebase should proceed without incident in-memory, so we can see tracebacks rather than fallbacks. This makes it easier to try and debug when things are broken. Differential Revision: https://phab.mercurial-scm.org/D8623
-
- May 18, 2020
-
-
Augie Fackler authored
This avoids some pointless copying. Differential Revision: https://phab.mercurial-scm.org/D8566
-
- Jan 15, 2021
-
-
Jörg Sonnenberger authored
In preperation for updating the reverse-branch-cache incrementally whenever a new changeset comes in, avoid bad performance on resize with Python 3.7 (and likely other 3.x versions). Differential Revision: https://phab.mercurial-scm.org/D9778
-
- Jan 17, 2021
-
-
Pierre-Yves David authored
This get useful for running analysis of the current algorithm. Differential Revision: https://phab.mercurial-scm.org/D9813
-
- Jan 18, 2021
-
-
Jörg Sonnenberger authored
Accessing the revlog by node is slightly more expensive than by revision, so look up the revision first and use it afterwards. Differential Revision: https://phab.mercurial-scm.org/D9831
-
Jörg Sonnenberger authored
Look-up by node is slightly more expensive, so since it is necessary more than once, do it explicitly. Differential Revision: https://phab.mercurial-scm.org/D9830
-
- Jan 19, 2021
-
-
Martin von Zweigbergk authored
The conflict markers created by `:mergediff` were not detected as conflicts, which affects both `commands.resolve.mark-check` and `mergetools.<tool>.check`. This patch fixes that. The new regex it uses for finding conflict markers is less restrictive because it `:mergediff` doesn't follow the `<<<<<<<` and `>>>>>>>` lines by a space (and a description). Hopefully lines like that don't give too many false positives. We can add back the space and make `:mergediff` add trailing spaces if it turns out to be a problem. OTOH, there will always be some false positives and we have ways of overriding the checks already. This patch can go onto the default or stable branch, depending on how much we care about an experimental feature. Differential Revision: https://phab.mercurial-scm.org/D9835
-
Martin von Zweigbergk authored
The function has been unused ever since it was introduced in 465b9ea02868 (Import 3-way merge code from bzr, 2007-04-16). Differential Revision: https://phab.mercurial-scm.org/D9832
-
- Dec 04, 2020
-
-
Pierre-Yves David authored
This is the one command namespace where they should not be any ambiguity about command that should be in it. The perf extensions is only adding performance related command. so this is a good ground to start putting dash folding to the tests. Differential Revision: https://phab.mercurial-scm.org/D9516
-
- Jan 19, 2021
-
-
Augie Fackler authored
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
The share-safe functionality is complete and all configuration options are implemented. The behavior is well discussed on mailing list and in reviews. Let's unmark this as experimental to solve a chichen and egg issue. Differential Revision: https://phab.mercurial-scm.org/D9823
-
- Jan 15, 2021
-
-
Pulkit Goyal authored
Config introduced in previous patch was `share.source-safe-mismatch`. Let's rename the warn as `share.source-safe-mismatch.warn`. While we are here, made sure we have different configs for upgrade and downgrade. Differential Revision: https://phab.mercurial-scm.org/D9786
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
Recently I implemented various boolean configs which control how to behave when there is a share-safe mismatch between source and share repository. Mismatch means that source supports share-safe where as share does not or vice versa. However, while discussion and documentation we realized that it's too complicated and there are some combinations of values which makes no sense. We decided to introduce a config option with 4 possible values which makes controlling and understanding things easier. The config option `share.safe-mismatch.source-{not-}safe` can have following 4 values: * abort (default): error out if there is mismatch * allow: allow to work with respecting share source configuration * {up|down}grade-abort: try to {up|down}grade, if it fails, abort * {up|down}grade-allow: try to {up|down}grade, if it fails, continue in allow mode I am not sure if I can explain 3 config options which I deleted right now in just 5 lines which is a sign of how complex they became. No test changes demonstrate that functionality is same, only names have changed. Differential Revision: https://phab.mercurial-scm.org/D9785
-
Pulkit Goyal authored
The share-safe functionality is complete and all configuration options are implemented. The behavior is well discussed on mailing list and in reviews. Let's unmark this as experimental to solve a chichen and egg issue. Differential Revision: https://phab.mercurial-scm.org/D9823
-
- Jan 15, 2021
-
-
Pulkit Goyal authored
Config introduced in previous patch was `share.source-safe-mismatch`. Let's rename the warn as `share.source-safe-mismatch.warn`. While we are here, made sure we have different configs for upgrade and downgrade. Differential Revision: https://phab.mercurial-scm.org/D9786
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
Recently I implemented various boolean configs which control how to behave when there is a share-safe mismatch between source and share repository. Mismatch means that source supports share-safe where as share does not or vice versa. However, while discussion and documentation we realized that it's too complicated and there are some combinations of values which makes no sense. We decided to introduce a config option with 4 possible values which makes controlling and understanding things easier. The config option `share.safe-mismatch.source-{not-}safe` can have following 4 values: * abort (default): error out if there is mismatch * allow: allow to work with respecting share source configuration * {up|down}grade-abort: try to {up|down}grade, if it fails, abort * {up|down}grade-allow: try to {up|down}grade, if it fails, continue in allow mode I am not sure if I can explain 3 config options which I deleted right now in just 5 lines which is a sign of how complex they became. No test changes demonstrate that functionality is same, only names have changed. Differential Revision: https://phab.mercurial-scm.org/D9785
-
- Jan 14, 2021
-
-
Pulkit Goyal authored
Earlier we used to allow shares which don't use share-safe mechanism to access repository which uses share-safe mechanism. This defeats the purpose and is bad behavior. This patch disallows that. Next patch will introduce a config option to allow that and have clearer understanding around various options. Differential Revision: https://phab.mercurial-scm.org/D9784
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
Since we are writing to repository, it's better to re-read after taking the lock. Differential Revision: https://phab.mercurial-scm.org/D9822
-
- Jan 14, 2021
-
-
Pulkit Goyal authored
The final config calculation code does not require a lock, only writing it back does require one. Differential Revision: https://phab.mercurial-scm.org/D9783
-
- Jan 18, 2021
-
-
Pierre-Yves David authored
The bad order was introduced in d0225a22040c. Differential Revision: https://phab.mercurial-scm.org/D9829
-
Matt Harbison authored
I'm not sure why this only happens with py3, but this error code doesn't map to any of the 3 currently being handled, and kills `run-tests.py` before it can run any tests when it happens: OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions The documentation[1] says this can happen if another process is bound to the address with exclusive access. This seems to keep it happy. [1] https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2 Differential Revision: https://phab.mercurial-scm.org/D9816
-
Matt Harbison authored
Windows doesn't have a `python3` executable, so cc0b332ab9fc attempted to work around the issue by copying the current python to `python3.exe`. That put it in `_tmpbindir` because of failures in `test-run-tests.t` when using `_bindir`, which looked like a process was trying to open it to write out a copy while it was in use. (Interestingly, I couldn't reproduce this running the test by itself in a loop for a couple of hours, but it happens constantly when running all tests.) The problem with using `_tmpbindir` is that it is the randomly generated path for the test run, and instead of Windows Firewall remembering the executable signature or image hash when allowing the process to open a server port, it apparently remembers the image path. That means every run will trigger a popup to allow it, which is bad for firing off a test run and walking away. I tried to symlink to the python executable, but that currently requires admin priviledges[1]. This will prompt the first time if the underlying python binary has never opened a server port, but appears to avoid it on subsequent runs. [1] https://bugs.python.org/issue40687 Differential Revision: https://phab.mercurial-scm.org/D9815
-
Matt Harbison authored
ef771d329961 skipped the check for the `tic` executable, because the curses module alone on Windows is enough to pass the `test-*-curses.t` tests. However, `test-status-color.t` uses this same check and explicitly invoked the executable, which fails on Windows. From the cursory searching I did, curses on unix requires `tic`, which I assume is why they were tied together in the first place. So this continues to require both to get past the curses guards on non Windows platforms. Differential Revision: https://phab.mercurial-scm.org/D9814
-
Jörg Sonnenberger authored
There are known issues with transactions not being closed in a timely fashion, making the test flakey. Differential Revision: https://phab.mercurial-scm.org/D9821
-
- Jan 15, 2021
-
-
Pierre-Yves David authored
The project have a default config of latest for this variable. Differential Revision: https://phab.mercurial-scm.org/D9792
-
- Jan 17, 2021
-
-
Pierre-Yves David authored
It appears that 2 bytes are never equals to 3 bytes. Differential Revision: https://phab.mercurial-scm.org/D9810
-
Pierre-Yves David authored
On Python 2, Missing file are IOError, not OSError, apparently. Differential Revision: https://phab.mercurial-scm.org/D9809
-
Matt Harbison authored
Might as well pick up the test coverage if it works as-is. Differential Revision: https://phab.mercurial-scm.org/D9808
-
- Dec 09, 2020
-
-
Matt Harbison authored
I noticed various `test-check-*` failures that were printing absolute paths when repo relative paths were expected. This was due to the drive letter in `repo.root` being uppercased as it is run through `os.path.realpath()`, and then the simple string comparison against the (lowercased) `_cwd` member of dirstate in `dirstate.getcwd()` causing an absolute path to be returned, instead of the expected `b''`. That in turn causes `scmutil.getuipathfn()` to wrongly use `repo.pathto()` with an absolute cwd path. . Differential Revision: https://phab.mercurial-scm.org/D9806
-