On Tue, Jul 9, 2013 at 4:53 PM, Ryan Schmidt
<subversion-2012c_at_ryandesign.com> wrote:
> On Jul 9, 2013, at 15:47, Stefan Sperling wrote:
>> On Tue, Jul 09, 2013 at 10:02:00PM +0200, Andreas Krey wrote:
>>> On Tue, 09 Jul 2013 21:43:50 +0000, Stefan Sperling wrote:
>>> ...
>>>> I think using UTF-8 by default would be a good choice today. But it
>>>> certainly wasn't when the Subversion project was started years ago.
>>>> And we cannot change the existing default behaviour now. That would
>>>> create compatibility nightmares with existing working copies.
>>>
>>> You could still make the encoding settable in the WC configuration,
>>> and optionally make that default to utf8 in the checkout. Old WCs
>>> wouldn't be affected. If the filesystem doesn't know, the application
>>> should store a value. (This whole stuff is scary anyway.)
>>
>> Ok, fine. I can see that working and be useful. Apart from the fact
>> that we currently do not really have a concept of a per-WC configuration.
>>
>> But with the default set to the old behaviour please. We don't want
>> to cause surprises for unsuspecting users.
>>
>> This knob would have to be in the client config, I guess, and apply
>> to all working copies during checkout and update. The working copy
>> would of course need to remember the value of the config knob had
>> during the initial checkout (this can be stored in wc.db), and would
>> re-use that value even if the configuration knob is changed.
>
> What happens if you copy a working copy between filesystems that have different encodings?
>
> What happens if you copy a working copy from OS X or Windows (whose default filesystems already know the disk encoding) to Linux or other UNIX (whose popular filesystems don't), or vice versa?
You hve *precisely* the same kind of problem with svn:eol settings.
Received on 2013-07-10 03:57:36 CEST