On Wed, Jan 17, 2007 at 06:28:43PM -0600, Ryan Schmidt wrote:
>
> On Jan 17, 2007, at 17:17, Ross Boylan wrote:
>
> >The docs indicate that the server stores all filenames and logs as
> >UTF-8, but files appear to be kept as unmodified binaries. mime-type
> >can affect comparisons and eol-style can affect end of lines, but I
> >don't see anything dealing with the encoding per se (even if it is
> >part of the MIME type, and I'm not sure it is).
> >
> >I know that historically version control systems attempt to be clever
> >about their files has often led to problems, but it seems to me
> >conversions between encoding schemes are fairly well-defined, and
> >would be useful. (Yes, I know some conversions are impossible!).
>
> Subversion does not have this feature.
I was afraid of that.
> Subversion stores file
> contents unchanged, except for line ending conversion if you ask for
> it. I believe attempting to provide encoding conversion is risky.
> There is no well-established way to indicate what encoding a text
> file is using. There are svn auto-props, but that wouldn't help in
> all cases. For example, I write php files, most of which are in
> iso-8859-1, but many of which are in utf-8 instead.
>
I don't see why a property like "encoding" wouldn't work with a smart
client. Some of the files would indicate iso-8859-1; others would be
tagged utf-8.
> As a solution outside of Subversion, you can use iconv to convert
> your files to the correct encoding for your situation before putting
> them in the repository.
That won't help, because the conversion needs to happen when the files
come out. I can store the file in iso8859 or utf-8, but I have to
pick one of them. When I check it out into the other environment, the
file won't be interpreted correctly.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 18 02:28:59 2007