[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

bug: svn add accepts non-ASCII characters but svn ci crashes on them

From: Jonas De Vuyst <jdevuyst_at_gmail.com>
Date: 2004-07-04 16:46:06 CEST


I believe to have encountered a bug, but am sending this mail per
instructions on the web site and because I'm not sure what the
``correct'' behaviour should be like.

The problem is that when I 'svn add' a directory (I suppose this will
be true for files also) with non-ASCII characters in its name, those
characters are blindly copied into .svn/entries. This is a problem
because when I subsequently run 'svn ci' I get an XML parse error
('invalid token' it says, with mention of the line where the weird
char is at).

The filenames in question are encoded in iso-8859-1. Specifically the
problem I'm having occurs at characters '' (176) and '' (233).

Ideally, I think, the filename would be converted to utf-8 (I notice
.svn/entries used this)or escaped to XML entities before being copied
into .svn/entries. The filename would then live as a utf-8 encoded
string in the repository. On checkout the filename would be translated
to iso-8859-1 again. This scenario assumes that svn somehow knows the
encoding used in filenames. I don't know how that should work though.

Alternatively perhaps the filename should as it currently happens be
copied literally still but the XML parser should be changed to accept
more characters. This solution strikes me as the most obvious one. But
perhaps it is obviously wrong.

A last possibility would be to only accept ASCII characters. In that
case a nicer error message would be appreciated. :-)

Thoughts would be appreciated (like should I file a bug, did I do
something brain dead, &c.).


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 4 16:47:45 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.