- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- May 02, 2022
-
-
Raphaël Gomès authored
The dirstate already is capable of verifying its integrity (although v2 features are not yet checked), let's run that code in `hg verify`.
-
- Jan 11, 2022
-
-
Pierre-Yves David authored
The feature have been around for a year (4 version) and is quite important. Lets make it enabled by default. Differential Revision: https://phab.mercurial-scm.org/D11997
-
- Dec 08, 2021
-
-
Pierre-Yves David authored
This give the "same" result, while taking in account that the requirement file might be in different location, like what `share-safe` is doing. Differential Revision: https://phab.mercurial-scm.org/D11895
-
- Nov 10, 2021
-
-
Raphaël Gomès authored
None of those outputs failed on the CI because dirstate-v2 is not fully tested yet. This also updates the documentation. Differential Revision: https://phab.mercurial-scm.org/D11746
-
- Oct 19, 2021
-
-
Pierre-Yves David authored
It seems the format as reached a good balance. With a core of new capabilities that motivated it initially and enough new feature and room for future improvement to be a clear progress we can set a milestone for. Having the format frozen will help the feature to get real life testing, outside of the test suite. The feature itself stay experimental but the config gains a new name to avoid people enable non-frozen version by default. If too many bugs are reported during the RC we might move the format back to experimental and drop its support in future version (in favor of a new one) Differential Revision: https://phab.mercurial-scm.org/D11709
-
- May 19, 2021
-
-
Simon Sapin authored
Fix most test failures (except in test-narrow-debugrebuilddirstate.t and test-upgrade-repo.t) caused by the new entry in config or in .hg/requires when running `run-tests.py --extra-config-opt format.exp-dirstate-v2=1` There is no CI so far for this configuration. Differential Revision: https://phab.mercurial-scm.org/D10718
-
- Jan 14, 2021
-
-
Pierre-Yves David authored
As discussed at the 5.6 sprint, we can make it enabled by default, but only for Rust installation. Differential Revision: https://phab.mercurial-scm.org/D9765
-
- Apr 06, 2021
-
-
Pierre-Yves David authored
As see in changeset bb271ec2fbfb, zstd is 20% to 50% faster for reading and writing. Use take advantage of the new config behavior to try zstd by default, falling back to zlib is zstd is not available on that plateform. Differential Revision: https://phab.mercurial-scm.org/D10326
-
- Nov 23, 2020
-
-
Martin von Zweigbergk authored
Some types of exceptions had a trailing "!" printed after the message from the exception itself. I guess some of these errors seem a little more severe (?), but it seems more likely that the inconsistency was just an oversight. Differential Revision: https://phab.mercurial-scm.org/D9378
-
- Sep 13, 2020
-
-
Yuya Nishihara authored
I don't think the order matters. Maybe it's purely because of the use of walkchangerevs(), which was originally designed for "hg log" command. Surprisingly, the number of objects fetched in test-largefiles.t has changed. According to the --verbose output, the order of the following fetches flipped and the latter got deduplicated. getting large3:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store getting sub/large4:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store
-
- Oct 14, 2018
-
-
Pierre-Yves David authored
We are going to improve the way this message is issued in the core codebase. This will make it appears for `hg debugobsolete` too. Since this seems like a good idea, we make the output change in a previous changesets to clarify the next changeset.
-
- Jul 02, 2019
-
-
sliquister authored
Currently, the files list of merge commits repeats all the deletions (either actual deletions, or files that got renamed) that happened between base and p2 of the merge. If p2 is the main branch, the list can easily be much bigger than the change being merged. This results in various problems worth improving: - changelog is bigger than necessary - `hg log directory` lists many unrelated merge commits, and `hg log -v -r commit` frequently fills multiple screens worth of files - it possibly slows down adjustlinkrev, by forcing it to read more manifests, and that function can certainly be a bottleneck - the server side of pulls can waste a lot of time simply opening the filelogs for pointless files (the constant factors for opening even a tiny filelog is apparently pretty bad) So stop listing such files as described in the code. Impacted merge commits and their descendants get a different hash than they would have without this. This doesn't seem problematic, except for convert. The previous commit helped with that in the hg->hg case (but if you do svn->hg twice from scratch, hashes can still change). The rest of the description is numbers. I don't have much to report, because recreating the files list of existing repositories is not easy: - debugupgradeformat and bundle/unbundle don't recreate the list - export/import tends to choke quickly applying patches or on description that contain diffs, - merge commits from the convert extension don't have the right files list for reasons orthogonal to the current commit - replaying the merge with hg update/hg merge/hg revert --all/hg commit can end up failing in hg revert - I wasn't sure that using debugsetparents + debugrebuilddirstate would really build the right thing I measured commit time before and after this change, in a case with no files filtered out, several files filtered out (no difference) and 5k files filtered out (+1% time). Recreating the 100 more recent merges in a private repo, the concatenated uncompressed files lists goes from 1.12MB to 0.52MB. Excluding 3 merges that are not representative, then the size goes from 570k to 15k. I converted part of mozilla-central, and observed file list shrinking quite a bit too, starting at the very first merge, 733641d9feaf, going from 550 files to 10 files (although they have relatively few merges, so they probably wouldn't care). Differential Revision: https://phab.mercurial-scm.org/D6613
-
- Jun 20, 2019
-
-
Kyle Lippincott authored
I've chosen <40 as the target so that other languages that may have a 2x blowup in character count can still have a chance to fit into an 80 column screen. Previously, we would show a prompt like: ``` keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path? ``` On at least some systems, if readline was in use then the last line of the prompt would be wrapped strangely if it couldn't fit entirely on one line. This strange wrapping may be just a carriage return without a line feed, overwriting the beginning of the line; example (100 columns wide, 65 character filename, and yes there's 10 spaces on the end, I assume this is to handle the user inputting longest word we provide as an option, "unresolved"): ``` ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon ``` In some cases it may partially wrap onto the next line, but still be missing earlier parts in the line, such as below (60 columns wide, 65 character filename): ``` rev], or leave (u)nresolved for some/long/dir/name/that/do s/not/work/well/with/readline/file.txt? ``` With this fix, this looks like this on a 60 column screen: ``` tool vim_with_markers (for pattern some/long/dir/name/that/d oes/not/work/well/with/readline/file.txt) can't handle binar y tool meld can't handle binary tool vim_with_markers can't handle binary tool internal:merge3 can't handle binary tool merge can't handle binary no tool found to merge some/long/dir/name/that/does/not/work /well/with/readline/file.txt file 'some/long/dir/name/that/does/not/work/well/with/readli ne/file.txt' needs to be resolved. You can keep (l)ocal [working copy], take (o)ther [merge rev ], or leave (u)nresolved. What do you want to do? ``` Differential Revision: https://phab.mercurial-scm.org/D6562
-
- Jan 09, 2019
-
-
Matt Harbison authored
I ran into this when using `hg lfconvert --to-normal` (which uses the filemap class internally), and saw that commits with nothing but a branch change were dropped. We could put in an option that only lfconvert uses internally. But silently dropping anything other than a commit where all changes were excluded seems unintended. For example, there's a message in mercurial_sink.putcommit() if it drops an empty commit. (And the reason that isn't kicking in here is because lfconvert isn't passing --filemap, so the self.filemapmode conditional there is always False.) The naive change of `return not files` broke test-convert-filemap.t, so this is a little more elaborate than needed for converting from largefiles.
-
- Nov 12, 2018
-
-
Boris Feld authored
Now that sparse-revlog is enabled by default, we no longer needs it. Differential Revision: https://phab.mercurial-scm.org/D5346
-
Boris Feld authored
We are about to enable sparse-revlog globally. To help with reviewing the tests change, we isolate them in individual changesets. Differential Revision: https://phab.mercurial-scm.org/D5322
-
- Nov 01, 2018
-
-
Boris Feld authored
These changes are no longer necessary so we better drop them.
-
Boris Feld authored
Using configuration instead of environment variable has a strange effect on the output, but no impact on the end result.
-
- Sep 04, 2018
-
-
Meirambek Omyrzak authored
output before: "500 files, 2035 changesets, 2622 total revisions" output after: "checked 2035 changesets with 2622 changes to 500 files" new one was suggested in the comments inside the issue. Differential Revision: https://phab.mercurial-scm.org/D4476
-
- Aug 16, 2018
-
-
Gregory Szorc authored
This drops the number of failures with this extension to 3. Differential Revision: https://phab.mercurial-scm.org/D4286
-
- Apr 05, 2018
-
-
Gregory Szorc authored
Now that the simple store handles flags properly, a handful of the largefiles and lfs tests pass! Differential Revision: https://phab.mercurial-scm.org/D3147
-
- Apr 03, 2018
-
-
Gregory Szorc authored
Getting these tests to pass is more work than it is worth right now. Let's punt on it. Differential Revision: https://phab.mercurial-scm.org/D3063
-
- Apr 04, 2018
-
-
Gregory Szorc authored
format.usegeneraldelta defaults to true. Differential Revision: https://phab.mercurial-scm.org/D3057
-
- Jan 08, 2018
-
-
Pulkit Goyal authored
Currently we don't have a good functionality to abort the merge and tell user to do `hg update -C .` which can leads to different results if user missed the '.' and moreover does not align with other abort functionalities like rebase, shelve etc. This patch adds `hg merge --abort` which will abort the ongoing merge and take us back to the chagneset where we started from. Works in both cases when merge resulted in conflicts and when there were no conflicts. .. feature:: A `--abort` flag to merge command to abort the ongoing merge. Differential Revision: https://phab.mercurial-scm.org/D1829
-
- Dec 11, 2017
-
-
Matt Harbison authored
# skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
-
- Nov 29, 2017
-
-
Matt Harbison authored
The `hg lfconvert --to-normal` command uses the convert extension internally to work its magic, but that produced devel-warn messages if the convert extension wasn't loaded by the user. The test in fcd2f9b06629 (modified here) wasn't showing the warnings because the convert extension was loaded via $HGRCPATH. Most of the config options default to None/False, but 'hg.usebranchnames' and 'hg.tagsbranch' are supposed to default to True and 'default' respectively. The first iteration of this was to ui.setconfig() inside lfconvert, to force the convert extension to load. But there really is no precedent for doing this, and check-config complained that 'extensions.convert' isn't documented. Yuya suggested this alternative. This partially backs out 0d5a1175d0f9.
-
- Sep 28, 2017
-
-
Boris Feld authored
Extract 'experimental.evolution' = createmarkers as 'experimental.evolution.createmarkers'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.createmarkers'. Differential Revision: https://phab.mercurial-scm.org/D1149
-
- Sep 16, 2017
-
-
Augie Fackler authored
I have no idea if these changes are reasonable, but they look like they'd help on the Windows buildbot.
-
- Aug 14, 2017
-
-
Phil Cohen authored
Differential Revision: https://phab.mercurial-scm.org/D374
-
- Aug 04, 2017
-
-
Boris Feld authored
evolution* config has been rewritten in stabilization* in the previous patch, update tests file to use the new names. Differential Revision: https://phab.mercurial-scm.org/D249
-
- Jul 16, 2017
-
-
Boris Feld authored
This seems useful to have the number of obsoleted changesets when calling debugobsolete.
-
- Oct 16, 2015
-
-
Pierre-Yves David authored
This leads to a harmless test change.
-
- Oct 12, 2015
-
-
Siddharth Agarwal authored
We perform all that we can non-interactively before prompting the user for input via their merge tool. This allows for a maximally consistent state when the user is first prompted. The test output changes indicate the actual behavior change happening.
-
- Oct 09, 2015
-
-
Siddharth Agarwal authored
The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
-
- Jun 07, 2015
-
-
Matt Harbison authored
Previously, if there were any hidden changesets, the --lfa argument would cause the command to abort with a hint about using --hidden when it tripped over a hidden changeset.
-
- Jun 08, 2015
-
-
Matt Mackall authored
$TESTDIR is added to the path, so this is superfluous. Also, inconsistent use of quotes means we might have broken on tests with paths containing spaces.
-
- May 28, 2015
-
-
Matt Harbison authored
The logic in the convert extension is more advanced, supporting extra features like converting revision IDs in 'extras' (e.g. 'amend_source'), supports updating hashes in commit messages, and outputs an SHA map file. Rather than try to duplicate all of that, just use the existing code. Even though the convert extension supports user supplied options like filemap, etc, those features aren't available on the lfconvert interface. Therefore, it is safe to use the filemap mechanism (in memory) to handle the standin -> file rename. The convert extension handles the destination locking for this path. There was a comment in test-lfconvert.t about the hash on rev 5 being different because it was doing a better job than "hg remove" + "hg merge" + "hg commit". It isn't clear to me what was happening or why, but now the hashes match the original repo exactly after a roundtrip, which seems like a good idea. If there really was something beneficial about the previous behavior, perhaps merge can be changed so that everyone benefits. Converting to a largefiles repo still uses the original (limited) lfconvert logic.
-
- Aug 19, 2014
-
-
Aaron Kushner authored
When running 'hg config no_such_option', hg exited with a zero exit code. This change now exits with a 1 if the config option does not exist.
-
- Jul 26, 2014
-
-
Pierre-Yves David authored
This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
-