Thu, 05 Apr 2018 18:22:35 -0700 revlog: move parsemeta() and packmeta() from filelog (API)
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Apr 2018 18:22:35 -0700] rev 37442
revlog: move parsemeta() and packmeta() from filelog (API) 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
Thu, 05 Apr 2018 15:18:23 -0700 filelog: declare that filelog implements a storage interface
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Apr 2018 15:18:23 -0700] rev 37441
filelog: declare that filelog implements a storage interface 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
Thu, 05 Apr 2018 15:09:41 -0700 repository: define existing interface for file storage
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Apr 2018 15:09:41 -0700] rev 37440
repository: define existing interface for file storage 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
Thu, 05 Apr 2018 11:16:54 -0700 tests: run some largefiles and lfs tests with simple store
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Apr 2018 11:16:54 -0700] rev 37439
tests: run some largefiles and lfs tests with simple store 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
Wed, 04 Apr 2018 21:27:02 -0700 commands: don't violate storage abstractions in `manifest --all`
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 21:27:02 -0700] rev 37438
commands: don't violate storage abstractions in `manifest --all` 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
Wed, 04 Apr 2018 21:09:47 -0700 commands: document the layering violation in `manifest --all`
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 21:09:47 -0700] rev 37437
commands: document the layering violation in `manifest --all` 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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip