On Sunday 21 November 2004 11:02, Norbert Unterberg wrote:
> After trying some things, I wonder what level of UNICODE support
> subversion has or is supposed to have.
Subversion is totally ignorant of underlying file content, it treats all files
as binary blobs.
> What do I need to do to check in UNICODE text files (which encoding is
> supported), so that subversion still treats them as text files, doing
> all sorts of diff and CR/LF conversion?
>
> Adding a UTF-16 file (with/without BOM) adds it as binary (mime-type:
> applcation/octet-stream). svn diff is not possible. Changing the
> mime-type to text/plain allows a diff, but the output is not displayed
> with the correct encoding.
Now here we come to the exception to above rule: there is support for treating
a file as text, but that is mostly limited to ASCII, maybe it still works
more or less with other single-byte charsets or even UTF-8. If I were you, I
would consider a) dropping UTF-16 altogether and b) storing files in UTF-8,
because UTF-16 combines the worst of two worlds anyway. That's just my
opinion though, and I'm aware of the fact that for MS Windows targetters it
is tempting to use the native encoding, but let's not discuss that here.
In order to allow diffing of other files, Subversion will get a pluggable diff
system, so you can diff files however you want and even extend that to new
file formats yourself. Until then, on the client side, you still have the
'original' in the .svn subdir which you can use to diff with your changes.
Everything else(i.e. with older versions, merging in changes) will require
repository access.
hth
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 21 13:10:49 2004