- 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
-
- 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
-
-
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 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
-
- Jan 16, 2021
-
-
Pierre-Yves David authored
Currently all discovery start with testing local and remote heads. For analysis purpose we make it possible to disable that initial "handshake" and start discovery with the whole repository as undecided. Differential Revision: https://phab.mercurial-scm.org/D9801
-
- Jan 15, 2021
-
-
Pierre-Yves David authored
This work around any deviciency/limitation of the clone process. In our case this ensure the persistent nodemap exist with valid content. Ideally, the cloning process would also do "the right thing". However since older server will never be able to do "the right thing". The local workaround will be necessary anyway. I am not worried by the performance impact of this as `hg clone` is non-instant on large repositories where is could matters. Warming the cache if they are already correct is very fast. And if they are not already warm, this seems like a good time to do so. This impact various test as more cache are now warmed sooner, all the change should be harmless. Differential Revision: https://phab.mercurial-scm.org/D9789
-
- Jan 13, 2021
-
-
Pierre-Yves David authored
We make it the default, and document the behavior in the help for the main config option. Differential Revision: https://phab.mercurial-scm.org/D9762
-
Pierre-Yves David authored
And make it the default until we get an abort option. Differential Revision: https://phab.mercurial-scm.org/D9761
-
Pierre-Yves David authored
We should probably provide some standard for this in config item, but this is a quest for another adventure. Differential Revision: https://phab.mercurial-scm.org/D9760
-
Pierre-Yves David authored
Since the feature is publicly known as "persistent-nodemap" this seems better to reference it as "persistent-nodemap" in related config too. So we rename the option to `storage.revlog.persistent-nodemap.mmap`. Differential Revision: https://phab.mercurial-scm.org/D9756
-
Pierre-Yves David authored
This is necessary before we advertise the feature more. Differential Revision: https://phab.mercurial-scm.org/D9755
-
- Jan 15, 2021
-
-
Pierre-Yves David authored
This allow to control the effect of the growth rate on the discovery process while doing analysis. Differential Revision: https://phab.mercurial-scm.org/D9799
-
- Jan 09, 2021
-
-
Martin von Zweigbergk authored
We assumed that the files in the `.hg/shelved/` directory have an extension. That's a valid assumption except that users may put garbage in the directory. This patch fixes the crash by simply not assuming that the result of splittin a string at '.' yields an extension. We don't use the extension since the previous patch anyway. Differential Revision: https://phab.mercurial-scm.org/D9720
-
- Jan 11, 2021
-
-
Martin von Zweigbergk authored
Before this patch, if a shelved change is missing its `.hg` file, we still list it in `hg shelve --list`, but then `hg unshelve` crashes. This patch makes it so we only list valid shelved changes. This patch means that users who do `touch .hg/shelve/buy-milk.patch` as a form of TODO list will no longer see their TODO items in `hg shelve --list`. Differential Revision: https://phab.mercurial-scm.org/D9719
-
- Jan 07, 2021
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9699
-
Martin von Zweigbergk authored
The only place we call `shelvedfile.opener()` is when we're about to apply a bundle. The file should always exist. If it doesn't, the `.hg/` directory is corrupt and we don't provide any guarantees about supporting corrupt repos (besides, telling the user that the shelve doesn't exist when `hg shelve --list` lists it is not very helpful). Differential Revision: https://phab.mercurial-scm.org/D9698
-
Martin von Zweigbergk authored
The code would try to delete the shelf's .patch file and if that raised an exception, it would convert it to an `error.Abort`. This patch rewrites it so the check is done upfront. I find it easier to read that way. It's now clear enough that I removed the comment explaining it as well. As Joerg pointed out during review, another differences is that the old code would move a `.hg` file without its `.patch` friend to backup before it realized that the `.patch` file was missing. The new code will error out earlier and not move the `.hg` file, which seems like an improvement. That should only matter on corrupt `.hg/shelved/` directories, however. Differential Revision: https://phab.mercurial-scm.org/D9697
-
- Jan 09, 2021
-
-
Martin von Zweigbergk authored
I don't care much how we behave in these cases, except that we should provide a way for the user to get out of the broken state. Differential Revision: https://phab.mercurial-scm.org/D9718
-
- Jan 14, 2021
-
-
Pierre-Yves David authored
That test is quite slow, lets split it in smaller bits. Differential Revision: https://phab.mercurial-scm.org/D9768
-
Pierre-Yves David authored
This open the way to splitting this slow test in multiple ones. Differential Revision: https://phab.mercurial-scm.org/D9767
-
- Jan 15, 2021
-
-
Pierre-Yves David authored
We need more than the python module, we also need the sqlite3 command line. Differential Revision: https://phab.mercurial-scm.org/D9787
-
- Jan 14, 2021
-
-
Martin von Zweigbergk authored
Command errors (unknown or ambiguous commands, or bad command arguments or options) are handled in the `dispatch` module. Most other errors are handled in the `scmutil` module. This patch therefore has to duplicate a little bit of code from the `scmutil` module. It's just a few lines, however, so it seems fine to me. It's a pretty common category of errors, so it's important to have them respect `ui.detailed-exit-code`. Differential Revision: https://phab.mercurial-scm.org/D9777
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9776
-
Pierre-Yves David authored
Since issue6150 is still not fixed, we have to accommodate a larger array of possible results. Otherwise we get frequent flakiness of local and CI runs. Differential Revision: https://phab.mercurial-scm.org/D9766
-
- Jan 13, 2021
-
-
Augie Fackler authored
Also only under python 3. Differential Revision: https://phab.mercurial-scm.org/D9752
-
- Dec 18, 2020
-
-
Jörg Sonnenberger authored
The branchhead computation is one of the more heavy operations for bigger repositories as it has to scan all changesets and potentially involves the expensive computation of the ancestor sets. Redo the computation to handle the common cases directly and use tighter conditions for when the ancestor scan is necessary. Most importantly, avoid it completely if the non-continous branches are processed in one update as seen in the initial computation after a clone. For the Mercurial repository, it gives a small 2-3% performance boost. For the NetBSD test repository, it cuts the time in half. Differential Revision: https://phab.mercurial-scm.org/D9631
-
- Jan 12, 2021
-
-
Pierre-Yves David authored
This make sure they are will be selected during upgrade, and copy based clone. Differential Revision: https://phab.mercurial-scm.org/D9749
-
Pierre-Yves David authored
We have a local work-around, however having that data sent in the first place would be better. So we start with a test that monitor what is sent, and notice they are not. Differential Revision: https://phab.mercurial-scm.org/D9736
-
Pierre-Yves David authored
This is currently buggy. We add a test before fixing the bug. Differential Revision: https://phab.mercurial-scm.org/D9734
-
Pierre-Yves David authored
This is currently buggy. We add a test before fixing the bug. Differential Revision: https://phab.mercurial-scm.org/D9733
-
Pierre-Yves David authored
The persistent nodemap is actually missing after local and stream clone. We start by adding a test for the case that works so that we can compare output after the fix. Differential Revision: https://phab.mercurial-scm.org/D9732
-
Kyle Lippincott authored
I have no idea if this is *actually* supported by the patch file format, but at least when reading from a patch file created by running `hg shelve`, it is written out such that there's a trailing space after the second (`b`) filename. When we read the patch file, we remove the space before parsing the filenames, so it doesn't end up matching the other sources of what files are in the shelve. We observed this internally due to a wrapper around unshelve that called into patch.changedfiles, but `hg patch` is able to reproduce the issue as well, so I've included both tests. Differential Revision: https://phab.mercurial-scm.org/D9729
-
- Jan 08, 2021
-
-
Pulkit Goyal authored
After this patch, we have config option to control all aspects of shares when share source is upgraded or downgraded. Differential Revision: https://phab.mercurial-scm.org/D9692
-