- 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
-
Pulkit Goyal authored
If the source repository upgrades to use sharesafe mode, we show a warning in shares. This patch makes that warning configurable and some might not want their users see this warning. Differential Revision: https://phab.mercurial-scm.org/D9691
-
Pulkit Goyal authored
`--force-lock` sounds as if we are taking the lock however in reality it's the opposite. Differential Revision: https://phab.mercurial-scm.org/D9690
-
- Jan 06, 2021
-
-
Pulkit Goyal authored
Reasoning is same as previous patch which adds automatic upgrade support. Downgrade is required as if automatic upgrade is enabled, all shares upgrade and then source repository downgrades, shares won't work. We need to downgrade them. Differential Revision: https://phab.mercurial-scm.org/D9680
-
Pulkit Goyal authored
In past few months, we have developed a `share-safe` mode for sharing repository in which share source requirements and config values are shared with the shares. To get it rolling, an important task is to get these shares automatically upgraded. We are focusing on an installation where shares are created by scripts and test jobs. It will be difficult to manually upgrade these and we need some functionality to do so automatically. This patch introduces a config option to deal with it. If all of the following conditions are met, we upgrade the share repository automatically: * If the config option is enabled * Share source repository is share-safe enabled * Share is not share-safe enabled * Any command is run in the share Upgrading the share is pretty easy as it involves only editing the requirements file. Differential Revision: https://phab.mercurial-scm.org/D9679
-
- Jan 08, 2021
-
-
Pulkit Goyal authored
Before this patch, upgrade will process everything, re-clone all revlogs, write requirements file again even there is no change to be made. This patch makes it exit earlier. Differential Revision: https://phab.mercurial-scm.org/D9695
-
- Jan 12, 2021
-
-
Simon Sapin authored
This allows the rhg build for test-rhg.t to share compiled dependencies such as hg-core with the hg-cpython build for other tests. For context, my wrapper script for the typical edit-compile-test cycle now looks like this: (cd rust && cargo +nightly-2020-10-04 fmt) (cd rust && cargo build --release -p rhg) make --silent local PURE=--rust python test/run-tests.py --local "$@" Differential Revision: https://phab.mercurial-scm.org/D9728
-
Pierre-Yves David authored
Otherwise this can use the wrong python version, or worse, not find any python at all. Differential Revision: https://phab.mercurial-scm.org/D9730
-
- Jan 13, 2021
-
-
Martin von Zweigbergk authored
Git is about to change the default branch from "master" to "main". Recent versions has started warning about that, which makes tests fail. I assume the tests would fail in a different way once the default has changed. To make us compatible with that name change, let's set configure the default to be "master". That value makes the tests still work on older Git version (those where the default branch name is not configurable). Differential Revision: https://phab.mercurial-scm.org/D9746
-
- Jan 08, 2021
-
-
Pulkit Goyal authored
An upgrade operation which is not adding or removing anything should ideally error out. However, it does the whole cloning and everything. Next patch will fix it. Differential Revision: https://phab.mercurial-scm.org/D9694
-
- Dec 31, 2020
-
-
Pulkit Goyal authored
Differential Revision: https://phab.mercurial-scm.org/D9676
-
- Dec 16, 2020
-
-
Pulkit Goyal authored
Old style optimization names like `redeltaparent` were converted into `re-delta-parent` more than two years ago. The old names were kept around for sometime because of BC reasons. Refer 5608b5a6c323. The commit states the map is there for a while and we can drop them as the underlying command is a debug command. Differential Revision: https://phab.mercurial-scm.org/D9614
-
- Dec 14, 2020
-
-
Pulkit Goyal authored
Found while reading the code to refactor. Differential Revision: https://phab.mercurial-scm.org/D9583
-
Pulkit Goyal authored
It was not obvious what does deficieny means and every format upgrade can't be a deficiency. There are some format upgrades like compression levels, share-safe which can't be understood at deficiencies. A change can be an upgrade or downgrade, however this `finddeficiences()` only used to find upgrades. This patch renames the function and related variables to make things more clearer. The ui message also got improved which is a good thing. Next patch will rename deficiency in general across the upgrade code. Differential Revision: https://phab.mercurial-scm.org/D9582
-
- Jan 02, 2021
-
-
msuozzo authored
The existing "circle with vertical fill" character renders as full width in many terminals making the beautified symbols have uneven size. Additionally, the proposed "fisheye" character is the logic 'active' version of the current merge symbol, "bullseye." Differential Revision: https://phab.mercurial-scm.org/D9678
-
- Dec 07, 2020
-
-
Pierre-Yves David authored
I am tired to see people shooting themself in the foot with this. So lets add more warning. At that point we should probably rename it or add extra confirmation flag. This is a debug command anyway we can break BC on it. Differential Revision: https://phab.mercurial-scm.org/D9534
-
- Dec 14, 2020
-
-
Pierre-Yves David authored
This avoid some unrelated output changeset when adding more cases. Differential Revision: https://phab.mercurial-scm.org/D9589
-
Pierre-Yves David authored
This helps to keep track of existing branch when adding new cases. Differential Revision: https://phab.mercurial-scm.org/D9588
-
- Dec 26, 2020
-
-
Sushil Khanchi authored
In dry-run mode, even when there was no rebase in progress it tried to abort (for context, at the end of dry-run mode we abort the in-memory performed rebase) because we were not early checking if there was any rebase started. Changes in test file reflect the fixed behavior. Differential Revision: https://phab.mercurial-scm.org/D9659
-
Sushil Khanchi authored
In dry-run mode, the case when there is nothing to rebase is not handled correctly. Added test show that it try to abort a rebase while there is no rebase in progress. This will be fixed in next patch. Differential Revision: https://phab.mercurial-scm.org/D9658
-