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?
