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 ]
Christian Ebert <blacktrash@gmx.net> [Thu, 02 Jun 2011 00:12:10 +0100] rev 963
Merge with 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 ]
Christian Ebert <blacktrash@gmx.net> [Sat, 28 May 2011 15:16:55 +0100] rev 961
Merge with 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 ]
Christian Ebert <blacktrash@gmx.net> [Sat, 28 May 2011 03:19:16 +0100] rev 959
Merge with 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 ]
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 ]
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 ]
Idan Kamara <idankk86@gmail.com> [Fri, 27 May 2011 17:46:47 +0300] rev 955
run-tests: slightly simplify blacklist check
[ original upstream message ]