- Apr 06, 2018
-
-
Gregory Szorc authored
rawsize() is not reimplemented outside of revlog. I'm not sure why this code was insisting it call a specific implementation. Changing it to call rawsize() on the repo.file(f) result seems to work just fine. Differential Revision: https://phab.mercurial-scm.org/D3153
-
Gregory Szorc authored
The upgrade code should never encounter a vanilla revlog instance: only changelog, manifestrevlog, and filelog should be seen. The previous code assumed !changelog & !manifestrevlog meant file data. So this change feels pretty safe. If nothing else, it will help tease out typing issues. Differential Revision: https://phab.mercurial-scm.org/D3152
-
- Apr 05, 2018
-
-
Gregory Szorc authored
Previously, the revlog class implemented dummy methods for various censor-related functionality. Revision censoring was (and will continue to be) only possible on filelog instances. So filelog implemented these methods to perform something reasonable. A problem with implementing censoring on filelog is that it assumes filelog is a revlog. Upcoming work to formalize the filelog interface will make this not true. Furthermore, the censoring logic is security-sensitive. I think action-at-a-distance with custom implementation of core revlog APIs in derived classes is a bit dangerous. I think at a minimum the censor logic should live in revlog.py. I was tempted to created a "censored revlog" class that basically pulled these methods out of filelog. But, I wasn't a huge fan of overriding core methods in child classes. A reason to do that would be performance. However, the censoring code only comes into play when: * hash verification fails * delta generation * applying deltas from changegroups The new code is conditional on an instance attribute. So the overhead for running the censored code when the revlog isn't censorable is an attribute lookup. All of these operations are at least a magnitude slower than a Python attribute lookup. So there shouldn't be a performance concern. Differential Revision: https://phab.mercurial-scm.org/D3151
-
- Apr 06, 2018
-
-
Gregory Szorc authored
filelog.parsemeta() and filelog.packmeta() are used to decode and encode metadata for file copies and censor. An upcoming commit will move the core logic for censoring revlogs into revlog.py. This would create a cycle between revlog.py and filelog.py. So we move these metadata functions to revlog.py. .. api:: filelog.parsemeta() and filelog.packmeta() have been moved to the revlog module. Differential Revision: https://phab.mercurial-scm.org/D3150
-
- Apr 05, 2018
-
-
Gregory Szorc authored
Now that we have a declared interface, let's declare that filelog implements it. Tests have been added that confirm the object conforms to the interface. The existing interface checks verify there are no extra public attributes outside the declared interface. filelog has several extra attributes. So we added a mechanism to suppress this check. The goal is to modify the filelog class so we can drop this check. Differential Revision: https://phab.mercurial-scm.org/D3149
-
Gregory Szorc authored
Now that we have mostly successfully implemented an alternate storage backend for files data, let's start to define the interface for it! This commit takes the mostly-working interface as defined by the simple store repo and codifies it as the file storage interface. The interface has been split into its logical components: * index metadata * fulltext data * mutation * everything else I don't consider the existing interface to be great. But it will help to have it more formally defined so we can start chipping away at refactoring it. Differential Revision: https://phab.mercurial-scm.org/D3148
-
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
-
Gregory Szorc authored
Previously, we asked the store to emit its data files. For modern repos, this would use fncache to resolve the set of files then would stat() each file. For my copy of the mozilla-unified repository, this took 3.3-10s depending on the state of my filesystem cache to render 449,790 items. The previous behavior was a massive layering violation because it assumed tracked files would have specific filenames in specific directories. Alternate storage backends would violate this assumption. The new behavior scans the changelog entries for the set of files changed by each commit. It aggregates them into a set and then sorts and prints the result. This reliably takes ~16.3s on my machine. ~80% of the time is spent in zlib decompression. The performance regression is unfortunate. If we want to claw it back, we can create a proper storage API to query for the set of tracked files. I'm not opposed to doing that. But I'm in no hurry because I suspect ~0 people care about the performance of `hg manifest --all`. .. perf:: `hg manifest --all` is likely slower due to changing its implementation to respect storage interface boundaries. If you are impacted by this regression in a meaningful way, please make noise on the development mailing list and it can be dealt with. Differential Revision: https://phab.mercurial-scm.org/D3119
-
Gregory Szorc authored
This commit fixes the last test failures when using the simple store extension! It turns out that `hg manifest --all` locks the repo and scans for revlogs. This feature was added by 71938479eff9 in 2011. I am debating changing the behavior. But that can occur in another commit. As part of debugging this, I realized that test-manifest.t is the only meaningful tester of `hg manifest --all` and that test was improperly disabled when bundlerepos aren't supported. The test is testing manifest behavior, not whether you can `hg pull` from a bundle. So I changed the test to `hg unbundle` instead. FWIW, I wasted a non-trivial amount of time tracking down this failure. I thought the issue involved Git, which is why I refactored the test to be more deterministic. Never in my mind would I have guessed that code in `hg manifest` would scan revlogs. I should have looked there to begin with. Doh. Differential Revision: https://phab.mercurial-scm.org/D3118
-
Gregory Szorc authored
There were a couple of bugs around the implementation of flags processing with the simple store. After these changes, test-flagprocessor.t now passes! test-flagprocessor.t was also updated to include explicit test coverage that pushed data is as expected on the server. The test extension used by test-flagprocessor.t has been updated so it monkeypatches the object returned from repo.file() instead of monkeypatching filelog.filelog. This allows it to work with extensions that return custom types from repo.file(). The monkeypatching is rather hacky and probably is performance prohibitive for real repos. We should probably come up with a better mechanism for registering flag processors so monkeypatching isn't needed. Differential Revision: https://phab.mercurial-scm.org/D3116
-
Gregory Szorc authored
Otherwise extensions loaded via --extra-config-opt could prevent access to the repo by introducing requirements file. This does mean that custom extensions loaded in this way won't impact this test. I'm fine with that. Differential Revision: https://phab.mercurial-scm.org/D3115
-
Gregory Szorc authored
test-run-tests.t invokes run-tests.py. But custom extensions providing new repo requirements may be in play and may not get inherited by the new run-tests.py. We ensure our repo is created with a vanilla config to mitigate extension-caused badness. Differential Revision: https://phab.mercurial-scm.org/D3114
-
Gregory Szorc authored
The keyword extension is hooking into repo.file() and defining its own filelog class. It will likely require a more formal storage interface before keywords are usable with alternate storage backends. Differential Revision: https://phab.mercurial-scm.org/D3113
-
Gregory Szorc authored
Parts of the test were assuming the use of revlogs with fnstore path encoding. Other parts of the test assumed we could create repos with different store encodings and that stream clone bundles worked. Make all of this conditional on running a revlog repo. Differential Revision: https://phab.mercurial-scm.org/D3112
-
Gregory Szorc authored
The test (which should probably be rewritten as a .t test - the test was initially authored in 2009 and this may have predated some test harness features allowing us to implement it as a .t test) is verifying symlink behavior with regards to working directory operations. How it pulls bundle data into a repo is not relevant. So we can switch from pull to unbundle so we can support environments where bundlerepos don't work. Differential Revision: https://phab.mercurial-scm.org/D3111
-
- Apr 04, 2018
-
-
Gregory Szorc authored
We mass disabled stream clone tests in a previous commit. Looks like one was missed. Differential Revision: https://phab.mercurial-scm.org/D3110
-
Gregory Szorc authored
This is testing how discovery between 2 well-defined repos works, not that `hg pull` works with bundles. Switch to `hg unbundle` so it works in environments where bundlerepos aren't supported. Differential Revision: https://phab.mercurial-scm.org/D3109
-
Gregory Szorc authored
This tests is doing tons of revlog-y things. It should be possible to make verification work across multiple stores. But it will likely have to wait until we have better abstractions in place. Differential Revision: https://phab.mercurial-scm.org/D3108
-
Gregory Szorc authored
If running with extra extensions we get an output difference. Differential Revision: https://phab.mercurial-scm.org/D3107
-
Gregory Szorc authored
This test is massive and could probably be split up. This change essentially requires the revlog store for stream clone tests and support for bundlerepos for various tests operating on bundle files. Differential Revision: https://phab.mercurial-scm.org/D3106
-
Gregory Szorc authored
This test is doing a number of low-level things with revlogs. Mark it as requiring the revlog store. Differential Revision: https://phab.mercurial-scm.org/D3105
-
- Apr 05, 2018
-
-
Gregory Szorc authored
This ensures that transaction rollback reverts the index to its previous state. This fixed a few test failures due to `hg verify` complaining about a reference to an undefined changeset revision. Differential Revision: https://phab.mercurial-scm.org/D3104
-
- Apr 04, 2018
-
-
Gregory Szorc authored
I think these are failing because of issues with flags processing in the simple store. Let's revisit this later. Differential Revision: https://phab.mercurial-scm.org/D3103
-
Gregory Szorc authored
Differential Revision: https://phab.mercurial-scm.org/D3102
-
Gregory Szorc authored
The simple store is using a primitive filename encoding scheme. Many tests in this file fail. So let's disable it for now. At some point, we should support a mode where we can run tests without fnstore or dotencode and have all tests assuming use of these filename encoding mechanisms be conditional on their usage. Differential Revision: https://phab.mercurial-scm.org/D3101
-
Gregory Szorc authored
Differential Revision: https://phab.mercurial-scm.org/D3100
-
Gregory Szorc authored
It /should/ be possible to support repos statically hosted on HTTP servers with alternate stores. But it's more trouble than it is worth right now. Let's just disable the test. Differential Revision: https://phab.mercurial-scm.org/D3099
-
Gregory Szorc authored
Various tests are failing when the simple store extension is loaded because the test overrides HGRCPATH and preempts loading of extensions that were injected via --extra-config-opt. In most cases, it is acceptable to always load the global HGRCPATH. So this commit changes a couple of tests so the global HGRCPATH is still pulled in. Differential Revision: https://phab.mercurial-scm.org/D3098
-
Gregory Szorc authored
The verifier issues warnings when the set of files in .hg/store doesn't align with the set of files that are advertised via repo.file(f).files() for all files seen in ctx.files() changelog traversal. This logic is reasonable for a default implementation. But some stores may have extra files whose presence is harmless. Or those stores may not have the same transaction rollback semantics that unlink files as other stores. This commit adds support for disabling the warning for orphaned files. The simple store extension has been taught to set this flag. Differential Revision: https://phab.mercurial-scm.org/D3097
-
Gregory Szorc authored
Working my down the long tail of test failures due to the simple store. We're now down to 38 failures with the simple store. Differential Revision: https://phab.mercurial-scm.org/D3096
-
Gregory Szorc authored
Before, we used the default store, which was based on fncache and dotencode. After attempting to port tests to work with the simple store, I realized that fncache was more trouble than it is worth. This commit implements a proper store type for the simple repo - one that isn't based off fncache. This causes a number of new test failures because of tests expecting the full fncache store filename encoding. I may extend the store format in a subsequent commit to take the filename encoding parts of fncache that we can take (basically everything except hash encoding, since that isn't reversible). But for now, let's use encoded store. As part of this, we implement proper requirements support for repos created with the simple store. This should have been done from the beginning, as a requirement is needed to lock out clients that don't understand a storage format. A new hghave feature advertising the presence of fncache in repos has been added. Most tests touching the fncache are now conditional on that feature. Other tests have added the optional repo requirement to output. Differential Revision: https://phab.mercurial-scm.org/D3095
-
- Feb 27, 2018
-
-
Jörg Sonnenberger authored
Introduce a new option server.streamunbundle which starts a transaction immediately to apply a bundle instead of writing it to a temporary file first. This side steps the need for a large tmp directory at the cost of preventing concurrent pushes. This is a reasonable trade-off for many setups as concurrent pushes for the main branch at least are disallowed anyway. The option defaults to off to preserve existing behavior. Change the wireproto interface to provide a generator for reading the payload and make callers responsible for consuming all data. Differential Revision: https://phab.mercurial-scm.org/D2470
-
- Apr 06, 2018
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D3171
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D3170
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D3169
-
- Apr 04, 2018
-
-
Gregory Szorc authored
Not all stores may be backed by revlogs. Switch to a more generic error message. Differential Revision: https://phab.mercurial-scm.org/D3094
-
Gregory Szorc authored
Previously, the walking mechanism assumed the use of revlogs for storage. Making the file filter configurable will enable custom stores to override _walk() so it recognizes additional files. Differential Revision: https://phab.mercurial-scm.org/D3093
-
Gregory Szorc authored
When revisions or nodes can't be resolved, we're expected to raise an error.LookupError. When I ported code from revlog.py, I failed to realize that "LookupError" in that module is aliased to error.LookupError. I thought we were using the builtin LookupError instead. This commit switches us to error.LookupError. It also fixes rev() to raise error.LookupError instead of KeyError. Differential Revision: https://phab.mercurial-scm.org/D3092
-
Gregory Szorc authored
And mark the test as requiring the revlog store. Differential Revision: https://phab.mercurial-scm.org/D3091
-
Gregory Szorc authored
Censor assumes the use of revlogs. Proper censor support for non-revlog storage will require a better abstraction in the storage layer to remove data. Let's skip the censor tests until we have something in place. Differential Revision: https://phab.mercurial-scm.org/D3090
-