[Cc to the dev@ list] On 2013-07-19 16:50:49 +0200, Stefan Sperling wrote: > On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote: > > [...] > > > > Actually I think that the encoding needs to be stored somewhere in the > > working copy. Otherwise even if the user never changes the encoding, > > problems may occur, and this is also true with the current behavior. > > Indeed it was said in the past that USB keys were supported. So, move > > a USB key to a different computer, where the encoding specified by the > > environment is different... and see what happens if you try to do an > > "svn update"... > > Simply storing the encoding doesn't really solve anything. Sure, it > remembers the LC_CTYPE value as the time the working copy was created. > But then... what?
At least it would work better. And in some cases, one wouldn't notice any problem. For instance, a repository (and therefore the corresponding working copies too) may contain mostly filenames with only US-ASCII characters, and when moving a USB key to another computer, one may be interested only in a part of the working copy with such filenames. > We also need to specify some new behaviour that increases user > convenience for such a new feature to have any value. > > For this, we need answers to questions like: > How can the client detect whether the stored encoding name matches > the on-disk encoding? What does it do when they differ? How can users > re-encode filenames in the working copy when on-disk encoding has changed? I don't understand what you mean here. If the chosen encoding for the filenames is stored in the working copy: The on-disk encoding has been chosen by Subversion (at checkout time). So, initially it matches the stored encoding. This normally doesn't change... unless the user has explicitly chosen to re-encode the filenames globally with some tool. In such a case, the user also needs to modify the stored encoding, and Subversion can provide a command for that. Subversion can also provide a command to re-encode the filenames of a working copy and update the stored encoding. The main problem is when a working copy is moved to another machine, on which the chosen encoding is not supported on the new machine. But I don't think Subversion can do anything about it. The user needs to make sure that the chosen encoding is supported on the new machine. This should be the case for ASCII (+ escaping mechanism) and UTF-8. > I'm very much interested in enhancements in this area, but at this > point we don't need to rehash all the problems there are. We need > to design solutions. This discussion needs a change of direction towards > being more constructive, or it will die with no results. The discussion > is also increasingly off-topic for the users@ list. > > In other words, I'm happy to continue this discussion on the dev@ list > and review your proposed design specs and patches there. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)