On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote:
> On 2013-07-19 15:22:33 +0200, Vincent Lefevre wrote:
> > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > In a context where, for example, most files were encoded in Big5
> > > (http://en.wikipedia.org/wiki/Big5) — not a too far-fetched proposition
> > > — it would be slightly insane, to put it mildly, for Subversion to
> > > assume it can just write UTF-8 to disk.
> >
> > Users who want UTF-8 on disk could choose UTF-8 in a config file.
> > Users who want Big5 on disk could choose Big5 in a config file.
> > There should also be a way to have ASCII encoding (like what is
> > done for URL's), for users who want things to work in every context
> > with the possibly-minor drawback of having some filenames that are
> > hardly readable with basic tools.
> [...]
>
> 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?
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'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.
Received on 2013-07-19 16:51:29 CEST