- Dec 15, 2020
-
-
Pierre-Yves David authored
We are looking into moving away from TimeStampedPathCopy (that use is_ancestors call to detect overwrite) in favor of an approach that does not requires is_ancestors calls. Yet we will still need an internal representation that differs from the returned result. So we call it "InternalPathCopies" which is generic but clear. Differential Revision: https://phab.mercurial-scm.org/D9641
-
- Dec 12, 2020
-
-
Pierre-Yves David authored
We now detect and record when a merge case required special logic (eg: thing that append during the merge, ambiguity leading to picking p1 data, etc) and we explicitly mark the result as superseding the previous data. This fixes the family of test we previously added. Differential Revision: https://phab.mercurial-scm.org/D9613
-
- Dec 14, 2020
-
-
Pierre-Yves David authored
To properly handle the newly tested case (chaining of merges) we will need to detect more accurately when an actualy merging of the copy information (and superseed the two existing data). Before starting to do so, we need to reorganise the values comparison to introduce different conditional branches when such actual merging is needed/detected. To avoid mixing too many change in this complicated code, we do the reorganisation before adding the "overwrite detection" logic in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D9612
-
- Feb 22, 2021
-
-
Pierre-Yves David authored
This is similar to the chaining test we have for the A/E merges. The current result of this tests is wrong, as for the other test of the same familly. This will be fixed by a later changesets. Differential Revision: https://phab.mercurial-scm.org/D10059
-
Pierre-Yves David authored
That case involve a branch overwriting copies information from the other one. It is similar to the `mBFm` / `mFBm` case except this case actual content merge is involved too. Differential Revision: https://phab.mercurial-scm.org/D10058
-
- Feb 19, 2021
-
-
Pierre-Yves David authored
That case involves conflicting copies information from each branch. It is similar to the `mAEm` / `mEAm` case except this case actual content merge is involved too. Differential Revision: https://phab.mercurial-scm.org/D10057
-
Pierre-Yves David authored
This branch will be used to create merge case that mirror ones involving the `e` branch. Differential Revision: https://phab.mercurial-scm.org/D10056
-
Pierre-Yves David authored
This branch will be used to create merge case that mirror ones involving the `a` branch. Differential Revision: https://phab.mercurial-scm.org/D10055
-
Pierre-Yves David authored
The initial branch is moving some of the "same content" file around. We do the same for the "different content" before start to implement more tests. The new files have harmless impact of various existing tests. Differential Revision: https://phab.mercurial-scm.org/D10054
-
Pierre-Yves David authored
The new `p`, `q` and `r` file mirror the `a`, `b` and `h` but with different content for each files. This will be used to create "mirror" test case that involve actual merge happening. For now, we only add the file to keep patches small and easier to review. Differential Revision: https://phab.mercurial-scm.org/D10053
-
Pierre-Yves David authored
This is similar to the chaining test we have for the A/E merges (without change). The current result of this tests is wrong, as for they "without change counter part". This will be fixed by a later changesets. Differential Revision: https://phab.mercurial-scm.org/D10052
-
- Feb 22, 2021
-
-
Pierre-Yves David authored
Checks inline comment for details.
-
- Feb 19, 2021
-
-
Pierre-Yves David authored
It is not really useful for the tests and is a large source of churn when adding more revisions to the tests. Differential Revision: https://phab.mercurial-scm.org/D10050
-
Pierre-Yves David authored
The revision number are not very informative and can change when new changeset are added, creating unnecessary churn. We change the template before adding more test to improve clarify of the over changesets. Differential Revision: https://phab.mercurial-scm.org/D10049
-
- Feb 17, 2021
-
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10048
-
- Dec 14, 2020
-
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9611
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9610
-
- Feb 16, 2021
-
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9609
-
- Feb 18, 2021
-
-
Pierre-Yves David authored
This make the transitions between case clearer. Differential Revision: https://phab.mercurial-scm.org/D10047
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10046
-
- Feb 16, 2021
-
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10045
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10044
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10043
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10042
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10041
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10040
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10039
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10038
-
Pierre-Yves David authored
This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10037
-
Pierre-Yves David authored
Right now, everything mostly says "simple merge", we want to use something a bit more descriptive. Before doing any changes, we do most of the churn. This helps the next sets of changesets to be clearer. Differential Revision: https://phab.mercurial-scm.org/D10036
-
- Feb 22, 2021
-
-
Pierre-Yves David authored
For main case (using filelog or sidedata), this lead to the following hash change. Changesets: - 01c2f5eabdc4ce2bdee42b5f86311955e6c8f573 → 319179230cc87769ab3a861ebffe7a534ebb3d85 - 01c2f5eabdc4 → 319179230cc8 - c72365ee036fca4fb27fd745459bfb6ea1ac6993 → 6cbc9c2b7b391dd738603173717c601648d3735f - c72365ee036f → 6cbc9c2b7b39 File revision for `f`: - 0dd616bc7ab1a111921d95d76f69cda5c2ac539c → cedeacc5bf5d9b9be4d7f8394d33a5349bb29c6e - 0dd616bc7ab1 → cedeacc5bf5d - eb806e34ef6be4c264effd5933d31004ad15a793 → ffb76cd765422a18759a335d8a81fa2bd455be6b - eb806e34ef6b → ffb76cd76542 - 6da5a2eecb9c833f830b67a4972366d49a9a142c → 08d1ff5926fbd0285cdeb044cbe8ab651687e86a - 6da5a2eecb9c → 08d1ff5926fb File revision for `d`: - 7bded9d9da1f7bf9bf7cbfb24fe1e6ccf68ec440 → ba177bbb45ea930ee48469a55d40224537bd57a9 For the "extra in changeset" case we get the following change for file `d`: - 68d5bca9df0577b6bc2ea30ca724e13ead60da81 → b894de5c94aadcb4894ea7c358389819c27fbcce - 68d5bca9df05 → b894de5c94aa - b80de5d138758541c5f05265ad144ab9fa86d1db → 56647659eff080e06e45c18ea9e848836dadea71 - b80de5d13875 → 56647659eff0
-
- Dec 10, 2020
-
-
Pierre-Yves David authored
This effectively back out changeset deeb215be337. Changeset deeb215be337 does not really include a justification for its change and make mes uncomfortable. I have been thinking about it and they are two options: - either having empty/full files does not make a difference, and deeb215be337 is a gratuitous changes. - either having empty/full files do make a difference and deeb215be337 silently change the test coverage. In such situation if we want the "not empty" case to be tested, we should add new cases to cover them In practice, we know that the "file content did not change, but merge still need to create a new filenode" case exists (for example if merging result in similar content but both parent of the file need to be recorded), and that such case are easy to miss/mess-up in the tests. Having all the file using the same (empty) content was done on purpose to increase the coverage of such corner case. As a result I am reinstalling the previous test situation. To increase the coverage of some case involving content-merge in test-copies-chain-merge.t, we will add a new, dedicated, cases later in this series, once various cleanup and test improvement have been set in place. This changeset starts with reinstalling the previous situation as (1) it is more fragile, so I am more confided getting it back in the initial situation, (2) I have specific test further down the line that are base on these one. The next changeset will slightly alter the test to use non-empty files for these tests (with identical content). It should help to make the initial intent "merge file with identical content" clearer. I am still using a two steps (backout, then change content) approach to facilitate careful validation of the output change. Doing so has a large impact on the output of the "copy info in changeset extra" variant added in 5e72827dae1e (2 changesets after deeb215be337). It seems to highlight various breakage when merge without content change are involved, this is a good example of why we want to explicitly test theses cases. Because the different -do- matters a lot. Fixing the "copy info in changeset extra" is not a priority here. Because (1) this changeset does not break anything, it only highlight that they were always broken. (2) the only people using "copy info in changeset extra" do not have merge. Differential Revision: https://phab.mercurial-scm.org/D9587
-
- Feb 10, 2021
-
-
Pulkit Goyal authored
Similar to what we do on upgrade, if we have only persistent-nodemap to downgrade we will just delete the nodemap files and update repository requirements instead of processing all the revlogs. After downgrade, we are left with unrequired docket and transaction files which seems fine but can work on deleting them if someone feels we should. Differential Revision: https://phab.mercurial-scm.org/D9992
-
- Feb 15, 2021
-
-
Pulkit Goyal authored
In 98e39f04d60e I assumed that writing nodemap for manifests was not desirable and stopped writing it during upgrade. However in recent discussion with Pierre-Yves, I learnt that that's not true. Differential Revision: https://phab.mercurial-scm.org/D9991
-
- Feb 23, 2021
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D10061
-
Martin von Zweigbergk authored
D9955 changed the version format to replace "-" by "." and to add "hg" before the number representing the distance from the latest tag. However, it missed the "hg" string and added an extra "." to the version string we produce when there's a `.hg_archival.txt`. This patch makes it consistent. Differential Revision: https://phab.mercurial-scm.org/D10060
-
- Feb 11, 2021
-
-
Kyle Lippincott authored
There are other packages that depend on python3-mercurial, like debian's mercurial-git, so we should mark ourselves as providing it. I compared the control file we generate to the one that the debian maintainers generate, and noticed several differences: - the Homepage bit. I included this, because why not - a more robust Suggests list that includes a graphical merge tool - a more robust Breaks list - debian's Recommends openssh-client, we only Recommends ca-certificates - a split into `mercurial` and `mercurial-common` (and possibly others?) - a slightly different description Differential Revision: https://phab.mercurial-scm.org/D9983
-
- Feb 12, 2021
-
-
Raphaël Gomès authored
This is currently not used by anything in core (and redundant with the url), the real source information is much more useful. This is going to be used in sidedata exchange patches coming soon. Differential Revision: https://phab.mercurial-scm.org/D9986
-
Kyle Lippincott authored
For commands like `hg bookmarks`, where there's no `[+] marked option can be specified multiple times`, this causes the final option in the option list to not be the parent of the aliases definition. The aliases section is thus marked as a blockquote like on commands that do have text separating the option list and the aliases definition. Differential Revision: https://phab.mercurial-scm.org/D9990
-
Kyle Lippincott authored
We manage our installation and ship some extensions, enabled by default for our users, that are in hgext3rd or other directories not scanned by this tool by default. We want to generate docs during the build process, and having those docs include the extensions that users don't have to manually enable is desirable. This is *not* desirable for the normal build process, however, and should never be enabled by default. Differential Revision: https://phab.mercurial-scm.org/D9989
-