Well my point is that this would not work everywhere.
How can "store as bytes" not work (be implementable?) everywhere? I'm
missing something.
When stored/returned as bytes, certainly a filename might look like
garbage when presented to the user, depending on their locale, what the
It's also documented [1].
https://svnbook.red-bean.com/en/1.7/svn.advanced.l10n.html
Thanks. I failed to find that. Now I understand.
I certainly don't expect such fundamental behavior to change, but I
can't help but respond a little. Just ignore me :).
All the world is not Unix
The most classic example is "FILE.TXT" versus "file.txt". According to
To repeat: I'm not talking about case clashes and similar underlying
filesystem problems; other people brought those up.
I'm asking specifically about the failure of the unasked-for
"UTF-8 conversion", which, so far as I
Perhaps «export LC_ALL=C.UTF-8», if your platform has that encoding?
Yes, thanks, that is one of the workarounds. But that's not my
question.
My question is, why can't svn just treat the filenames as bytes? I
remain baffled by the need to unconditionally convert to/from UTF-8 (or
any other
A file with a name that has some "eight-bit" UTF-8 bytes (fn...-utf8.tex)
was committed to one of my repositories. When I try to check it out in
the C locale, svn complains:
$ echo $LC_ALL
C
$ svn update
svn: E22: Can't convert string from 'UTF-8' to native encoding:
svn: E22:
If you really used Python 2.6 (not Python 2.7)
You are right, I (that is, CentOS 7) has python 2.7.5.
Sorry about misstatement. -k
With svn-1.14.0, if "python" is Python 2 (it's still 2.6.6 on CentOS7),
and --with-swig is given, make swig-py succeeds, but check-swig-py fails
with:
cd /usr/local/src/subversion-1.14.0/subversion/bindings/swig/python; \
/usr/local/bin/python
With svn-1.14.0, if --without-berkeley-db is given to configure, and
--with-swig is given, make swig-pl succeeds, but check-swig-pl fails
with:
make[1]: Entering directory
'/home/local/src/subversion-1.14.0/subversion/bindings/swig/perl/native'
"/home/local/bin/perl" -MExtUtils::Command::MM -e
I tried running
svn log -l 1 foo bar
to try to see the last log message for files foo and bar, but get:
svn: E27: When specifying working copy paths, only one target may be given
which surprised me. Is there any way to do this in one svn command?
Of course I could do it with a shell loop or
Is it possible to read (no need to write) svn configuration settings via
some svn command?
That is, something better than trying to discover the location of the
configuration file(s) and grepping or otherwise parsing them. That's a
road I don't want to go down.
Specifically, what I want to know
The vc-svn.el file at
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/emacs/vc-svn.el
for svn support in Emacs 21 broke with the change in Subversion that
puts .svn only at the top level of a repository. Now the
(vc-svn-registered) test for whether a file is in a Subversion
Nico, Tobias - thanks for the replies, although I wasn't looking for
advice exactly :).(*)
I was merely pointing out that the vc-svn.el file in the Subversion
repository says specifically for Emacs 21, and it doesn't work with
current Subversion, and thus I thought Subversion (not Emacs) might
12 matches
Mail list logo
