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 ]
(0) -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 tip