I\'ve got a post-commit hook script that performs a SVN update of a working copy when commits are made to the repository.
When users commit to the repository from th
It changes the encoding to a location-neutral encoding in case someone with a different encoding checks it out.
Of course. But it's not "Windows" ASCII (Windows actually uses some strange encoding like CP1251 or so).
The best way to fix this is to make sure that your system uses UTF-8 whenever possible (check $LANG
).
I got a similar problem when running "svn add" on a directory, but the solution was different. I couldn't see the "hex" digits using printf (actually no hex output was shown by svn), but this command allowed me to see the results, and fix it:
LC_ALL=C svn add probealign
I think, in general, sticking LC_ALL=C before your command allows you to see the offending files... and is a lot easier than pasting in a lot of \x72 stuff (which apparently may not be available).
In my case, I had the setting in ~/.subversion/config as below
log-encoding = ...
Commenting it worked.
If Error is -
[abc@288832-web3 public_html]$ svn update
svn: Error converting entry in directory 'images' to UTF-8
svn: Valid UTF-8 data
(hex: 46 65 6e 65 72 62 61 68)
followed by invalid UTF-8 sequence
(hex: e7 65 2b 46)
Then do this.
[abc@288832-web3 public_html]$ printf "\x46\x65\x6e\x65\x72\x62\x61\x68\n"
Fenerbah
(This means that the system has some file name starting with "Fenerbah" in that folder.)
[abc@288832-web3 public_html]$ cd images
[abc@288832-web3 images]$ rm -rf Fenerbahçe+Forma+2.jpg
So you can see that there is a special character in the name and it is not supported by SVN.
put this in your post-commit export LANG=xxxxx (your lang)
Just use the following line in your script before executing any svn command. User appropriate language codes, in following example I used japanese
export LC_ALL=ja_JP.UTF8