- Feb 22, 2025
-
-
Pierre-Yves David authored
This is a follow up to e6069f84abbb. It turns about that there are multiple test condition that needs cleanup. This handle the usage of the first one.
-
- Nov 18, 2024
-
-
Pierre-Yves David authored
The number of format to consider increase, this will make the command simpler to use in tests and debug. See test changes for some direct benefits.
-
- Sep 24, 2024
-
-
Pierre-Yves David authored
We want to ensure no older clients will truncate the file under us. So we need to change their name. We don't change the rest of the format (unfortunaly).
-
- Mar 10, 2024
-
-
Pierre-Yves David authored
Before this change, we were unconditionally writing a branchmap file for the filter level passed to `update_disk`. This is actually counter productive if no update were needed for this filter level. In many case, the branch cache for a filter level is identical to its parent "subset" and it is better to simply keep the subset update and reuse it every time instead of having to do identical work for similar subset. So we change the `update_disk` method to only write a file when that filter level differ from its parent. This removes many cases where identical files were written, requiring multiple boring update in the test suite. The only notable changes is the change to `test-strip-branch-cache.t`, this case was checking a scenario that no longer reproduce the bug as writing less branchmap file result in less stalled cache on disk. Strictly speaking, we could create a more convoluted scenario that create a similar issue. However the next changeset would also cover that scenario so we directly updated that test case to a "no longer buggy" state.
-
- Jan 07, 2022
-
-
Pierre-Yves David authored
With `share-safe`, the requirements are stored in multiple files so it seems better to use the command that retrieve the information wherever it is. Differential Revision: https://phab.mercurial-scm.org/D11985
-
- Dec 07, 2021
-
-
Pierre-Yves David authored
A share will use the same format as its source for the store, but there are no reason to not lets it control the working copy variant at creation time. So we make it so. Differential Revision: https://phab.mercurial-scm.org/D11892
-
- 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
-
- Oct 28, 2021
-
-
Pierre-Yves David authored
The previous code was overlooking fallback when neither symlink not exec was supported. The number of "variants" is getting too high, so I am consolidating this in a single closure that should be easier to maintains. This also ensure that fallback flags are always taken into account. (they are not user code yet, but small experimentation shown that the feature was working as intended.) A a small side effect we need to check for symlink support more lazily and this show up in the test in a couple of places. Differential Revision: https://phab.mercurial-scm.org/D11728
-
- Aug 03, 2021
-
-
sliquister authored
This commit is exactly the result of running this command: sed -i -e 's! *\(-e \|--ssh \|--config ui.ssh=\)[ \"]*$PYTHON[ \"]*$\(RUN\|\)TESTDIR/dummyssh[\"]* *! !g' -e '/^[ >]*ssh *=[ "]*$PYTHON[ "]*$\(RUN\|\)TESTDIR\/dummyssh[ "]*$/d' -e 's/^\( [$] .*[^ ]\) *$/\1/' *.t *.sh Sometimes the tests can be simplified further, but I think it's preferable to do the simplification separately. Differential Revision: https://phab.mercurial-scm.org/D11245
-
- May 07, 2021
-
-
Pierre-Yves David authored
That cache can quite expensive to compute on large repository as not that `hg clone` is warming all cache, this can introduces a significant slowdown for clone time[1]. As a stop gap measure introduce a quick fix for that on stable, skipping the fnodetags cache post-clone. [1] https://www.mercurial-scm.org/pipermail/mercurial/2021-April/052679.html Differential Revision: https://phab.mercurial-scm.org/D10695
-
- 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
-
-
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
-
- Dec 14, 2020
-
-
Jörg Sonnenberger authored
If a is shared to b and b cloned to c, the old code would look directly under b/.hg for the cache directory and not use the cachevfs layer to pick the members from a/.hg/cache. Adjust variable names and comments to reflect that the function is used for more than just the branchmap cache. Differential Revision: https://phab.mercurial-scm.org/D9598
-
- 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
-
- Apr 14, 2020
-
-
Pulkit Goyal authored
This introduces a config option which enabled stores the requirements on a repository in store instead. When enabled, `.hg/requires` will contain the `share-safe` requirement which marks that the requirements are present in the store. This is done so that repository requirements can be shared with shares made using `hg share` command. After this patch, `hg share` checks whether the source repository has share-safe requirement, if yes, it does not copy the requirements. Test for the new functionality is added and a test case in exitsing share tests is also added. Differential Revision: https://phab.mercurial-scm.org/D8633
-
- Jul 21, 2020
-
-
Pulkit Goyal authored
We cannot create a shared repository without a store IIUC. Let's abort in such cases. Differential Revision: https://phab.mercurial-scm.org/D8772
-
- Jun 04, 2019
-
-
Yuya Nishihara authored
These paths are useful for GUI applications to detect changes. A GUI process typically monitors .hg and .hg/store directories so that it will be notified on lock/wlock deletion. Alternatively, maybe we can add debugpaths command if we don't want to extend the root command. I'm not sure which will be nicer.
-
- May 15, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6384
-
- Mar 14, 2019
-
-
Pierre-Yves David authored
The manifest full text cache is tightly related to the working copy. We should use the `wcache` directory for it, instead of the `cache`. Otherwise, multiple shares would keep overwriting each other cache entry and we loose its benefit. This is also more consistent with the fact this cache file is protected by `wlock`.
-
- Mar 08, 2019
-
-
Matt Harbison authored
PYTHON was not getting mangled for MSYS style paths, and remote was spitting out remote: 'C' is not recognized as an internal or external command, remote: operable program or batch file. (once -q was removed). Additionally, this should fix a failure with py3 because of spaces in the path.
-
- Feb 20, 2019
-
-
Mitchell Plamann authored
Differential Revision: https://phab.mercurial-scm.org/D5985
-
Mitchell Plamann authored
Differential Revision: https://phab.mercurial-scm.org/D5984
-
- Dec 04, 2018
-
-
Matt Harbison authored
This goes with 47e3f554df35::d5622dfe4ba3. I'm not sure if it was really expected that there would be no wcache directory if neither execbit nor symlink is supported.
-
- Nov 15, 2018
-
-
Boris Feld authored
Some cache are relevant or affected by the working copy used. So the `.hg/cache` directory is not the best place for them because multiple shared repository can end up fighting over them. To address this issue, we introduce a new 'wcache' directory to host this kind of cache. The first user are the `checkisexec` type file. These files describe property of the working copy and fit the use-case well.
-
- Nov 20, 2018
-
-
Matt Harbison authored
This goes with bd0874977a5e.
-
- Nov 15, 2018
-
-
Boris Feld authored
Since 460733327640, a "share" use the cache of the source repository. A side effect is that no `.hg/cache` directory exists in the "share" anymore. As a result, the checkexec logic can't use it to create its temporary file and have to use the working copy for that. This is suboptimal, it pollutes the working copy and prevents them to keep the file around in cache. We do not want to use the cache directory for the share target, it might be on a different file system. So instead, we (try to) create the directory if it is missing. This is a simple change that fixes the current behavior regression on stable. On default, we should probably ensure the proper directories are created when initializing the repository. We should also introduce a 'wcache' directory to hold cache file related to the working copy. This would clarify the cache situation regarding shares. The tests catch a couple of other affected cases.
-
- Sep 20, 2018
-
-
Gregory Szorc authored
Previously, hg.share() had its own logic for creating a new repository on the filesystem. With the recent introduction of the createopts dict for passing options to influence repository creation, it is now possible to consolidate the repo creation code for both the normal and shared use cases. This commit teaches the repo creation code in localrepo to recognize when we're creating a shared repo and to act appropriately. Meaningful behavior should be identical. However, there are a few subtle changes: * The .hg/requires file is written out in sorted order (rather than having share-related requirements appended at end). * The .hg directory is created with notindexed=True when a shared repo is being created. Differential Revision: https://phab.mercurial-scm.org/D4707
-
- Sep 12, 2018
-
-
Gregory Szorc authored
As part of refactoring this code, I realized that we don't validate the requirements of a shared repository. This commit documents that next to the requirements validation code and adds a test demonstrating the buggy behavior. I'm not sure if I'll fix this. But it is definitely a bug that users could encounter, as LFS, narrow, and potentially other extensions dynamically add requirements on first use. One part of this I'm not sure about is how to handle loading the .hg/hgrc of the shared repo. We need to do that in order to load extensions. But we don't want that repo's hgrc to overwrite the current repo's. Differential Revision: https://phab.mercurial-scm.org/D4572
-
- Aug 15, 2018
-
-
Gregory Szorc authored
This file is currently specific to the revlog store. Other stores may not implement it. Mark it as such in test output. Differential Revision: https://phab.mercurial-scm.org/D4395
-
- Aug 18, 2018
-
-
Matt Harbison authored
-
- Jul 31, 2018
-
-
Martijn Pieters authored
Reconstructing the manifest from the revlog takes time, so much so that there already is a LRU cache to avoid having to load a manifest multiple times. This patch persists that LRU cache in the .hg/cache directory, so we can re-use this cache across hg commands. Commit benchmark (run on Macos 10.13 on a 2017-model Macbook Pro with Core i7 2.9GHz and flash drive), testing without and with patch run 5 times, baseline is r2a227782e754: * committing to an existing file, against the mozilla-central repository. Baseline real time average 1.9692, with patch 1.3786. A new debugcommand "hg debugmanifestfulltextcache" lets you inspect the cache, clear it, or add specific manifest nodeids to it. When calling repo.updatecaches(), the manifest(s) for the working copy parents are added to the cache. The hg perfmanifest command has an additional --clear-disk switch to clear this cache when testing manifest loading performance. Using this command to test performance on the firefox repository for revision f947d902ed91, whose manifest has a delta chain length of 60540, we see: $ hg perfmanifest f947d902ed91 --clear-disk ! wall 0.972253 comb 0.970000 user 0.850000 sys 0.120000 (best of 10) $ hg debugmanifestfulltextcache -a `hg log --debug -r f947d902ed91 | grep manifest | cut -d: -f3` Cache contains 1 manifest entries, in order of most to least recent: id: 0294517df4aad07c70701db43bc7ff24c3ce7dbc, size 25.6 MB Total cache data size 25.6 MB, on-disk 0 bytes $ hg perfmanifest f947d902ed91 ! wall 0.036748 comb 0.040000 user 0.020000 sys 0.020000 (best of 100) Worst-case scenario: a manifest text loaded from a single delta; in the firefox repository manifest node 9a1246ff762e is the chain base for the manifest attached to revision f947d902ed91. Loading this from a full cache file is just as fast as without the cache; the extra node ids ensure a big full cache: $ for node in 9a1246ff762e 1a1922c14a3e 54a31d11a36a 0294517df4aa; do > hgd debugmanifestfulltextcache -a $node > /dev/null > done $ hgd perfmanifest -m 9a1246ff762e ! wall 0.077513 comb 0.080000 user 0.030000 sys 0.050000 (best of 100) $ hgd perfmanifest -m 9a1246ff762e --clear-disk ! wall 0.078547 comb 0.080000 user 0.070000 sys 0.010000 (best of 100)
-
- Jun 05, 2018
-
-
Boris Feld authored
Using "published" seems smoother than "became public" and more in line with the "phase.publishing" configuration.
-
- Jun 04, 2018
-
-
Boris Feld authored
The current message is a bit generic. Since we only print it for phase movement on changeset already common before the pull, we add "local" to the message in and attempt to clarify what changeset the phase movement affected.
-
- May 24, 2018
-
-
Denis Laxalde authored
Upon pull or unbundle, we display a message with the number of changesets which phase became public. Noticeably, this new message would appear even if no new changeset were added (below the "no changes found" message), thus indicating that something actually happened to the local repository.
-
- May 01, 2018
-
-
Gregory Szorc authored
The killdaemons hghave feature has returned True since it was introduced in 448d0c452140. As such, "#require killdaemons" has no effect and is superfluous. So we remove instances of it. Differential Revision: https://phab.mercurial-scm.org/D3442
-
- 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)
-
- Aug 22, 2017
-
-
durin42 authored
-
- Jul 15, 2017
-
-
Boris Feld authored
Share extension now also share caches reads and writes. Not sharing caches results in costly caches recomputations which can takes up to minutes when using shares on large repositories. There are a couple of file in the '.hg/cache/' that depends of the current visibility. Visibility can be affected by the working copy location, something which is specific to each share. We ignores them for this series because they: * are the minority, * already have a good fallback to other precomputed caches, * are only affected when people use the experimental evolution feature.
-
- Jul 02, 2017
-
-
Katsunori FUJIWARA authored
Temporarily enabling largefiles causes these output lines, only if tests are executed with fsmonitor.
-
- Apr 12, 2017
-
-
Matt Harbison authored
This has been done for clone since e1dbe0b215ae, so it makes sense here for the same reasons.
-