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?
Received on 2013-07-09 22:53:55 CEST