2008/11/19 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>:
> The APC had always troubles with files containing bytes with the high
> bit set. Consequently t/op/regexp_unicode_prop_thr.t is now missing in
> the APC. Porting/patching.pod talks about this:
>
> =item Binary Files
>
> Since the patch(1) utility cannot deal with binary files, it's important
> that you either avoid the use of binary files in your patch, generate the
> files dynamically, or that you encode any binary files using the
> F<uupacktool.pl> utility.
>
> Assuming you needed to include a gzip-encoded file for a module's test
> suite, you might do this as follows using the F<uupacktool.pl> utility:
>
> $ perl uupacktool.pl -v -p -D lib/Some/Module/t/src/t.gz
> Writing lib/Some/Module/t/src/t.gz into lib/Some/Module/t/src/t.gz.packed
>
> This will replace the C<t.gz> file with an encoded counterpart. During
> C<make test>, before any tests are run, perl's Makefile will restore all
> the C<.packed> files mentioned in the MANIFEST to their original name.
> This means that the test suite does not need to be aware of this packing
> scheme and will not need to be altered.
>
> Rafael, do you still know how such a file can be decontaminated once
> it has been added to Perforce?
I think that the trick was to add a packed version of the
"contaminated" file in the source code of the APC tools.
Well, with the forthcoming git move, that kind of problem should
disappear. We should probably get rid of all .packed files and add a
.gitattributes files at the root to record which files are binary.
(Versioned metadata. Yay)
PS. My @mandriva email address is dead since two years...
Highlight