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 ?
Highlight