On Tue, Jul 9, 2013 at 4:53 PM, Ryan Schmidt <subversion-20...@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.
