[haiku-commits] Re: r37480 - haiku/trunk/src/data/keymaps
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sun, 18 Jul 2010 08:43:05 +0200
> We do not need patch svn, we just need to prohibit using any
> characters
> outside of first 127 ASCII bytes in the source names, IMO. I found
> this
> a "head over heal" situation when we propose patch the SCM instead of
> just removing the _real_ cause of incompatibility.
There IS a bug in our implementation of svn, leading to wrongly encoded
chars in the repository that anyone else cannot checkout. I don't want
to have stupid restrictions on Haiku because of such a bug. 7-bit ascii
is something of the last millenium, and BeOS even used utf-8 in
filenames 15 years ago without any problems. I don't see why we
couldn't do the same. It is part of the localization effort.
> Please do not overcomplicate the situation - there is one simple and
> reasonable way - do not use "problematic" characters in the names.
> BTW,
> the bug is not fixed until the "ReadMe.cross-compile" contains words
> that
>
> " We currently support these non-BeOS platforms:
> [...]
> * FreeBSD
> [...]
> "
>
> because at the moment we _cannot_ checkout the source tree on
> FreeBSD. :-(
It works fine for Build-O-Matic, so there is likely a way to get around
it.
I don't mind having 7-bit chars in the subversion tree if these aren't
visible to the user, but here the problem is the filename is used
directly for display in the keymap preflet. As the name of this keymap
_is_ bépo, and Haiku technically allows it, I don't see why a
limitation that is caused by a bug in svn build for Haiku should
prevent us from using it. Unless you have some way to display the
proper name in the keymap preflet without having to use "strange" chars
in the filename, I'm going to leave it this way.
Other related posts:
