Sat, 11 Jun 2011 14:17:25 +0200 patch: generalize the use of patchmeta in applydiff() stable
Patrick Mezard <pmezard@gmail.com> [Sat, 11 Jun 2011 14:17:25 +0200] rev 964
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 ]
Thu, 02 Jun 2011 00:12:10 +0100 Merge with stable
Christian Ebert <blacktrash@gmx.net> [Thu, 02 Jun 2011 00:12:10 +0100] rev 963
Merge with stable
Tue, 31 May 2011 20:39:04 -0500 run-tests: allow whitelisting tests that should always run stable
Augie Fackler <durin42@gmail.com> [Tue, 31 May 2011 20:39:04 -0500] rev 962
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 ]
Sat, 28 May 2011 15:16:55 +0100 Merge with stable
Christian Ebert <blacktrash@gmx.net> [Sat, 28 May 2011 15:16:55 +0100] rev 961
Merge with stable
Sat, 28 May 2011 11:44:27 +0200 run-tests: fix --blacklist (broken by 95715c2f90bf) stable
Patrick Mezard <pmezard@gmail.com> [Sat, 28 May 2011 11:44:27 +0200] rev 960
run-tests: fix --blacklist (broken by 95715c2f90bf) [ original upstream message ]
Sat, 28 May 2011 03:19:16 +0100 Merge with stable
Christian Ebert <blacktrash@gmx.net> [Sat, 28 May 2011 03:19:16 +0100] rev 959
Merge with stable
Fri, 27 May 2011 21:50:10 +0200 patch: use temporary files to handle intermediate copies stable
Patrick Mezard <pmezard@gmail.com> [Fri, 27 May 2011 21:50:10 +0200] rev 958
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 ]
Fri, 27 May 2011 21:50:09 +0200 patch: refactor file creation/removal detection stable
Patrick Mezard <pmezard@gmail.com> [Fri, 27 May 2011 21:50:09 +0200] rev 957
patch: refactor file creation/removal detection The patcher has to know if a file is being created or removed to check if the target already exists, or to actually unlink the file when a hunk emptying it is applied. This was done by embedding the creation/removal information in the first (and only) hunk attached to the file. There are two problems with this approach: - creation/removal is really a property of the file being patched and not its hunk. - for regular patches, file creation cannot be deduced at parsing time: there are case where the *stripped* file paths must be compared. Modifying hunks after their creation is clumsy and prevent further refactorings related to copies handling. Instead, we delegate this job to selectfile() which has all the relevant information, and remove the hunk createfile() and rmfile() methods. [ original upstream message ]
Fri, 27 May 2011 17:46:48 +0300 run-tests: fix --blacklist with jobs > 1 stable
Idan Kamara <idankk86@gmail.com> [Fri, 27 May 2011 17:46:48 +0300] rev 956
run-tests: fix --blacklist with jobs > 1 filter blacklisted tests before partitioning them to the children. maintains the 'Skipped...' output but not the 's'. [ original upstream message ]
Fri, 27 May 2011 17:46:47 +0300 run-tests: slightly simplify blacklist check stable
Idan Kamara <idankk86@gmail.com> [Fri, 27 May 2011 17:46:47 +0300] rev 955
run-tests: slightly simplify blacklist check [ original upstream message ]
(0) -300 -100 -10 +10 +100 +300 tip