Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <50815AB7.1020505@dominolaser.com>
Date: Fri, 19 Oct 2012 15:50:47 +0200
From: Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com>
Reply-To: users@subversion.apache.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: users@subversion.apache.org
Subject: Re: 200 OK error on update with files that contain non-alphanumeric
 characters
References: 
 <CAH_3vcRYZceJfgUVRU8ht_Shu_F9Tk-eu09HUKBu2nVburA5-w@mail.gmail.com>
In-Reply-To: 
 <CAH_3vcRYZceJfgUVRU8ht_Shu_F9Tk-eu09HUKBu2nVburA5-w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 19.10.2012 15:15, schrieb Gautier DI FOLCO:
> I have a quite annoying problem, I use svn 1.6.15 with mod_dav on Apache
> HTTPd 2.2.8 on the server side and sevral clients.
>
> On the client side, when I add and commit a file which has spaces or
> non-ASCII
> characters, all works, but, if I try do do an update, I have the following
> error:
> Updating '.':
> svn: E175002: REPORT of '/svn/!svn/vcc/default': 200 OK (https://serve)

This looks weird, "200 OK" actually means "success"...


> I try to checkout my repository in an other folder, then update works well,
> but all the filename are urlencoded.

Try "svn ls <remote URL>" to see the actual content. The problem could 
be that you really checked in those files urlencoded by accident (I 
assume you mean e.g. %20 instead of space).


> Is their a way to handle non-ASCII characters and espace in filenames or
> a way to be less annoying?

I have successfully stored files and directories with spaces and 
Cyrillic, Devanagari and some Japanese characters in Subversion and (of 
course) also created working copies for them. However, this was on MS 
Windows and also using svn://-URLs instead of HTTP or HTTPS.

As far as Subversion is concerned, there is surely no repository-side 
problem, because the repository stores paths as Unicode and doesn't care 
for spaces. It could only be that an ancient server version allowed 
paths with invalid encodings, it didn't always verify those, which 
effectively causes an invalid repository.

The problem I could imagine is the client side, where your filesystem 
must support the encoding and also the locale must be configured 
correctly. Lastly, if these are correct, there is also the possibility 
that there is some implementation issue with the client/server 
communication.

I would
  - Verify that the locale is set up correctly.
  - Try a different OS.
  - Try a different access method, svn:// or file://, the latter of 
course only on a local copy of the repository.

Uli

**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************