2012/2/1 Ignacio González (Eliop) <firstname.lastname@example.org>:
First, avoid non-ascii characters in file names.
> Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)
> Server: Linux (CentOS), svn 1.6.16 (Spanish)
> Repository created OK
> Hundreds of revisions already checked-in OK
> Hook "check-mime-type" (bash) added in server
> A couple of revisions checked-in OK
> New file added with non-ASCII characters -> Problem:
> Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
> (note the u with an acute accent: ú)
> C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
> Adding acentos
> Adding acentos\In£til.TXT
> Transmitting file data .svn: Commit failed (details follow):
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
> ?\195?\186til.TXT' failed with this output:
> svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist
> To help diagnose it, I tried to check out an already existing file with
> accents in its name
> (checked in before the Hook "check-mime-type" (bash) was added in the
> Check out fails.
> Oh, my God.
> Suggestions ?
Yes, I tend to do so, especially with software code.
But, al last, we convinced our hardware, marketing and field people
to use Subversion as well. Please don't suggest me to tell them to stop
naming the documents they produce without accents and ñ :-)
I can hear them: 'What the heck? Until yesterday I was able to navigate
with my web browser your repository and all the documents had the names I
gave them. You are telling me now that you are re-naming them? Crazy!'
It causes real
problems with pre-commit hooks
and post-commit hooks that do not
properly quote their arguments, and that's not something you can
handle on the client side. And I've had network file shares used for
working copies, such as NetApp serviced home directories NFS mounted
as /home/$USER on the Linux side and CIFS mounted $HOMEDIR on the
Windows side, where people generated files on the Windows side,
successfully checked them in, and couldn't successfully read or delete
the files on the Linux NFS side because the server hadn't been set up
with UTF compatible NetApp filesystems.
Second, can you check out the *directory* that ocntains the file by
using the directory name, and letting the client deal with the
Done it. No joy :-(
And can you use 'svn mv', or do your operations with a
TortoiseSVN client, which is really handy for getting files with funny
names correctly processed?
95 % of our uses use TortoiseSVN to check-in and check-out. Many of them
use a browser to surf the repository. In fact, the problems I reported were
found using TortoiseSVN, so the first thing I always do in these cases
is to check the problem with svn command line. In this case,
the observed behaviour was the same.
I cannot imagine a sensible way of using svn mv with the files that are already
checked-in with Windows clients and want to check out from Linux clients.
Is there some way to force the Linux server / svn server / svn hooks to use the
'Windows' filename convention, whatever it is?
Is there some way to reprocess (dump / load or whatever) the whole
repository in order to make happy both Linux clients and Windows clients
without changing the non-ASCII characters as seen by both clients?
What I was really surprised is to see that the filenames flowing through the
communication channel is not normalised (well, that is just speculation,
am I wrong?). Is there a way to force the clients to convert the names
to same canonical form (e.g., UTF-8) and back to the resident filesystem
What are doing my Czech, German and Turk friends in this forum?