develooper Front page | perl.perl5.porters | Postings from November 2008

Re: t/op/regexp_unicode_prop_thr.t marked as binary in APC

Thread Previous
From:
Rafael Garcia-Suarez
Date:
November 19, 2008 02:09
Subject:
Re: t/op/regexp_unicode_prop_thr.t marked as binary in APC
Message ID:
b77c1dce0811190209i12176360vcaacc158d2545cdf@mail.gmail.com
2008/11/19 Nicholas Clark <nick@ccl4.org>:
> On Wed, Nov 19, 2008 at 10:29:32AM +0100, Rafael Garcia-Suarez wrote:
>> 2008/11/19 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>:
>
>> > 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.
>
> In this case, I believe that I already fixed the metadata within perforce.
>
>> 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)
>
> I'm not convinced that that's reason alone.
>
> Perforce, also, is quite capable of holding binary files, yet we've chosen
> deliberately not to have any. I'm not sure of *all* of the reasons why, but
> one of them is it useful having the mailed diffs being canonical, rather than
> partial, because one can verify all the commits.

I don't think that reason alone was sufficient to go through the
hassle of setting up uupacktool.pl. Wasn't there a packaging reason as
well? Or maybe it was just for people reconstructing a bleadperl (or a
repository holding bleadperl) purely from the APC patches?

Basically, what will break if we unpack the binary files ?

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About