test: Changelog

patch: generalize the use of patchmeta in applydiff() - Add patchmeta.copy() and emit copies from iterhunks. Modifying patchmeta instances in applydiff() makes things simpler. - Rename selectfile() into makepatchmeta(). It is responsible for creating patchmeta for regular patches. - Pass patchmeta objects to patchfile() directly patchmeta instances were associated with git patches, for regular patches we had to pass additional variables to tell the patch intent to patchfile(). Instead, we generate patchmeta for regular patches and pass them. This will also help with patch filtering by matcher objects. [ original upstream message ]

run-tests: allow whitelisting tests that should always run It's desirable to run some tests all the time, for example test-check-pyflakes.t and test-check-code-hg.py. This allows passing --whitelist as a path to a file (flag can be specified more than once) which contains a list of files to whitelist. Whitelisted tests are run even if they're blacklisted or wouldn't match a --keyword test run. For example, to do a quick test of usehttp2, one can now do $ cat > test-whitelist <<EOF > test-check-pyflakes.t > test-check-code-hg.py > EOF $ (cd tests && ./run-tests.py --extra-config-opt 'ui.usehttp2=true' > -k http -j 8 --whitelist test-whitelist) and have all http-specific tests run as well as the two code linters. [ original upstream message ]

run-tests: fix --blacklist (broken by 95715c2f90bf) [ original upstream message ]

patch: use temporary files to handle intermediate copies git patches may require copies to be handled out-of-order. For instance, take the following sequence: * modify a * copy a into b Here, we have to generate b from a before its modification. To do so, applydiff() was scanning for copy metadata and performing the copies before processing the other changes in-order. While smart and efficient, this approach complicates things by handling file copies and file creations at different places and times. While a new file must not exist before being patched a copied file already exists before applying the first hunk. Instead of copying the files at their final destination before patching, we store them in a temporary file location and retrieve them when patching. The filestore always stores file content in real files but nothing prevents adding a cache layer. The filestore class was kept separate from fsbackend for at least two reasons: - This class is likely to be reused as a temporary result store for a future repository patching call (entries just have to be extended to contain copy sources). - Delegating this role to backends might be more efficient in a repository backend case: the source files are already available in the repository itself and do not need to be copied again. It also means that third-parties backend would have to implement two other methods. If we ever decide to merge the filestore feature into backend, a minimalistic approach would be to compose with filestore directly. Keep in mind this copy overhead only applies for copy/rename sources, and may even be reduced to copy sources which have to handled ahead of time. [ original upstream message ]