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

Re: [Issue 2194] Unicde UTF-16 files detected as binary

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-06 23:04:16 CET

Peter N. Lundblad wrote:

>On Thu, 6 Jan 2005, [UTF-8] Branko �^Libej wrote:
>
>
>
>>Peter N. Lundblad wrote:
>>
>>
>>
>>>On Thu, 6 Jan 2005, [UTF-8] Branko �^Libej wrote:
>>>
>>>
>>>
>>>
>>>
>>>>It is much more complicated than that. If we're to treat UTF-16 files as
>>>>text, we have to teach libsvn_diff to do diffs and merges correctly on
>>>>such files, and possibly enhance keyword expansion and newline
>>>>conversion, too.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Or convert to/from UTF8 as we do with other encodings.
>>>
>>>
>>>
>>>
>>We don't convert file /contents/ between encodings, we don't even know
>>which encoding they're in.
>>
>>
>>
>We don't know that *currently*.
>
Exactly. Bravo. And that change is where the can of worms is hidden,
because it's not only about writing, but also about parsing the files.

> That could change, however. Right now, we
>output UTF8 (I think, or is it native). Still, we just insert stuff in
>files without knowing the encoding.
>
Yes, we do broken things like that.

> So, I think we will want to add an
>encoding property (or support it in the svn:mime-type) someday.
>
>
Yup. We almost support it already, in the sense that we don't die it
it's there.

>Note that I don't say it is trivial, but it should be doable.
>
>
Neither did I say it wasn't doable, just that it frobs 90% of the
client-side code. But I admit this estimate might be a bit pessimistic;
it's probably closer to 85%. :-p

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 6 23:05:45 2005

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

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