First letter of file names missing in working copy window

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Updated version to svnx 1.3.1 and svn 1.7.1
2. Old working copies complain about svn version so:
3. Performed svn upgrade on working copies
4. Open again working copy in svnX

What is the expected output? What do you see instead?
 File names are missing their first letter in the window, but not in filesystem. Everything works fine except that filenames are not showed correctly in svnX.

What version of the product are you using? On what operating system?
svn 1.7.1 (from macports)
svnX  1.3.1

Please provide any additional information below.

Original issue reported on code.google.com by darthia on 9 Dec 2011 at 11:08

[GoogleCodeExporter]

I’m not seeing this.  [Not beyond the `svn upgrade` - which is a requirement 
of Subversion 1.7.]
What version of OSX are you using?
What is the path to your working copy?  Does it contain any unusual characters?

Please show the output of executing the following in Terminal.app:
    svn st --xml "<full-path-to-a-modified-WC-file>"
Where ‘full-path-to-a-modified-WC-file’ is a full path to a single, 
modified, file in your 1.7 working copy.

Original comment by chris...@gmail.com on 9 Dec 2011 at 10:59

[GoogleCodeExporter]

Hi, in my case, if the path to the WC has specific Japanese characters the path 
get trimmed.

The specific Japanese characters that I found are Hiragana with punctuations.

For example, please find "HIRAGANA LETTER GA" in 
http://tlt.its.psu.edu/suggestions/international/bylanguage/japanesecharthiragan
a.html

This letter is a combination of "HIRAGANA LETTER KA" and "KATAKANA-HIRAGANA 
VOICED SOUND MARK," and  in UTF, sometimes represented as one letter and in 
other cases as a combination of two letters.

I remember that MacOS handles them as one letter, and maybe, svn is handling 
them as two letters.

Working on Mac OS 10.6.8

DEV-KIM-Pro-S:trunk kim$ svn --version
svn, バージョン 1.7.2 (r1207936)
   コンパイル日時: Dec 26 2011, 14:00:46

svn is from macports built as +unicode_path variant.

Original comment by kim.take...@gmail.com on 26 Dec 2011 at 6:32

[GoogleCodeExporter]

Hi, I've checked out the path to my WC, and realized that the problem may be 
with the "unusual" characters found in it... 

For instance, when opening a WC in ~/Documents/Artículos (note the i has an 
acute accent) svnX does not show the first letter of files or dirs inside that 
WC path (deeper files in the tree are shown correctly).

However, when I performed an svn upgrade to ~/Documents/Informes and then 
opened it with svnX, everything was shown correctly, with all letters where 
they should be :)

Anyway, I executed svn st --xml as you asked me, and the output seems to be OK:

<?xml version="1.0" encoding="UTF-8"?>
<status>
<target
   path="/Users/josemgarcia/Documents/Artículos">
<entry
   path="/Users/josemgarcia/Documents/Artículos/josemgarcia-ESWC12">
<wc-status
   props="none"
   item="unversioned">
</wc-status>
</entry>
</target>
</status>

Finally, my MacOSX version is 10.6.8, and I am using svn from macports, versin 
1.7.2 and using the unicode_path variant.

Hope this helps

Original comment by darthia on 27 Dec 2011 at 9:36

[GoogleCodeExporter]

The problem is the ‘unicode_path variant’ patch.
It’s not part of the standard Subversion distribution for a reason - it 
breaks Subversion.

The solution is to get an unpatched/unhacked build of Subversion and …
If you are using repositories shared with Windows or Linux then avoid accented 
(composed) characters in file & directory names stored in the repo.  (They are 
allowable in the path to the WC folder, just not within the WC.)
If you are using Mac OS X only then everything should work normally.

The basic problem is that for file paths OSX uses decomposed characters 
[accented-char → plain-char + accent-char (2-chars)] & Windows uses 
pre-composed characters [accented-char → char+accent (1-char)].  The patch 
causes Subversion to convert all paths to pre-composed (NFC) form.  This means 
that paths returned by Subversion don’t match paths requested by svnX.  This 
should never happen without the patch/hack.

[To me it seems that the problem really lies in the interface between the 
client and the repository (path ⇄ URL).  This is internal to Subversion.  
They’ve know about the problem for over 6 years.  There doesn’t seem much 
interest in fixing it.
See <http://subversion.tigris.org/issues/show_bug.cgi?id=2464>.]

Original comment by chris...@gmail.com on 27 Dec 2011 at 12:51

[GoogleCodeExporter]

Hi Chris,

I understand the situation, but abandoning 'unicode_path variant' cannot be our 
choice.

Do you have any plan of bringing svnX back to open source, so that we can try a 
'unicode' branch?

I wonder why it was working with svn 1.6.

Takeshi

Original comment by kim.take...@gmail.com on 28 Dec 2011 at 1:10

[GoogleCodeExporter]

I agree with Takeshi. It was working well with svn 1.6, and actually all the 
subversion commands issued by svnX work flawlessly, but the WC tree does not 
show the files correctly, though I can operate with them without problems 
(except the Properties button, that seems to be broken). So it's just a matter 
of visual appeal.

Besides, I think that the problem is not because of the unicode_path variant, 
as the path to the working copy is outside the scope of svn. Files with accents 
in their names inside a WC work correctly. Forgive me if I misunderstood what 
unicode_path does.

Original comment by darthia on 30 Dec 2011 at 11:31

[GoogleCodeExporter]

Takeshi & darthia,

I have now created a custom build of Subversion 1.7.2 + unicode_path patch.
I can now recreate your problems.  (All due to the unicode_path patch.)

The issues are as follows:
    * For `svn status` the XML path attribute of <target> does not match the path attributes of each <entry>.
    [This is because the entry paths are passed through the svn_path_cstring_to_utf8 function but the target’s path is not.]
    * Similarly for `svn proplist` the path attribute of each <target> does not match the path attributes of from the original `svn status` <entry>.
    [Again this is because the target paths are not passed through the svn_path_cstring_to_utf8 function.]

I haven’t built Subversion 1.6.x + unicode_path patch, but I imagine that 
this is NOT the case there.
The problem is, basically, that the unicode_path patch is over 4 years old.  It 
pre-dates even Subversion 1.5.0.
The fact that you can still apply it to Subversion 1.7.2 is surprising.
The fact that IT DOES NOT WORK CORRECTLY is to be expected.
The fact that it did work with Subversion 1.6.x is mostly luck.  Unfortunately 
your luck ran out :-(.

However, who needs luck when you have a friend like me :-).
I have created an updated patch (for Subversion 1.7.2) that corrects the above 
issues and appears to allow it to work correctly with svnX.
[If you want the patch then contact me.  However, I take no responsibility for 
it — as I still believe that the whole concept is flawed.]

...

I know that the paths look the same, but they are not.
This doesn’t show in the sample send by darthia, probably because 
copy-and-paste messes with the encoding.
[But if you redirect the output to a file, open it in TextWrangler, select the 
target’s path & do Search > Find Selected Text … it won’t.]

I currently have no plans to release further source code for svnX.
[Nobody else has contributed any code to the project since I took over, so it 
is just a waste of my time.]
Anyway, I don’t think svnX is the place to try to fix this as clearly svnX is 
not where the problem is.

The problem is categorically due to applying the unicode_path patch (written 
for Subversion 1.4.x) to Subversion 1.7.x.
[Remember that the working copy code has radically changed in Subversion 1.7 
(WC-NG).]
The patch simply changes any decomposed Unicode characters into pre-composed 
ones for any string passed to the svn_path_cstring_to_utf8 function.
It knows nothing of paths or URLs let alone working copies.
[And the thought of having a path/string partly using decomposed Unicode & 
partly using pre-composed Unicode gives me the shivers.]

Original comment by chris...@gmail.com on 18 Jan 2012 at 6:38

[GoogleCodeExporter]

HUGE thanks for the thorough explanation and most importantly for your support. 
I understand and agree with you that it belongs to svn implementation. I think 
it's a shame it has not been patched in subversion yet.

anyway, as I still need to use both windows and mac, it could be great if you 
could give us the patch, maybe attaching it here. Don't worry, I'll take the 
responsibility if it breaks something :)

Again, thank you very much for your kind support!

Original comment by darthia on 18 Jan 2012 at 11:00

[GoogleCodeExporter]

THANK YOU Chris!

Same situation here, and it would also be great if we can have the patch, too.

Thank you for your wonderful support!

Original comment by kim.take...@gmail.com on 20 Jan 2012 at 12:55

[GoogleCodeExporter]

May you kindly send me tha patch, too?

Thanks a lot, Cesare

Original comment by cma...@gmail.com on 7 Feb 2012 at 10:53

[GoogleCodeExporter]

I’m closing this as the problem appears to be in MacPorts Subversion 1.7 
+unicode_path variant.
No one has reported any problems with svnX & Subversion 1.7 + my modified patch.

Original comment by chris...@gmail.com on 1 Mar 2012 at 1:59

• Changed state: Invalid