[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svn add' succeeds but errors out because file 'has binary mime type property'

From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
Date: 2006-07-15 18:20:15 CEST

On Jul 14, 2006, at 23:22, Sean McBride wrote:

> On 2006-07-13 14:25, Ted Dennison said:
>
>>> 3) utf16 files should be autodetected as text, not binary
>>
>> I'm not a Subversion dev, but I'm curious how would one go about
>> doing
>> this? Normal text files can be detected by the fact that no byte
>> in them
>> is larger than 7F.
>
> That's only true if you're talking about plain ASCII. Other encodings
> like MacRoman, UTF-8, ISO 8859, use the upper 128 chars for things
> like
> accented characters, see:
> <http://en.wikipedia.org/wiki/Extended_ASCII>
>
> I don't know, but I figured svn would be looking for patterns of CR/LF
> chars to guess if something is text. There is no sure-fire way to
> know
> of course.
>
> UTF-16 could also be detected by the BOM:
> <http://en.wikipedia.org/wiki/Byte_Order_Mark>

I think this is quite relevant:

http://subversion.tigris.org/issues/show_bug.cgi?id=2332

It discusses how Subversion should store the encoding of files either
within the svn:mime-type property (e.g. svn:mime-type = "text/html;
charset=utf-16") or in a new svn:encoding property (the latter of
which sounds better to me). If Subversion did (or allowed) this, then
svn diff and svn merge and friends could make use of this information
to properly handle UTF-16 and other encodings. UTF-16 (UTF-32, etc.)
files with byte-order markers could automatically be assigned the
correct encoding property, and files without a BOM could still have
it set manually by the user.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 15 18:22:27 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.