Hello, Nico.
El 1 de febrero de 2012 13:17, Nico Kadel-Garcia <nkadel_at_gmail.com>escribió:
2012/2/1 Ignacio González (Eliop) <igtorque.eliop_at_googlemail.com>:
> > 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:
> > /opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
> > `/opt/csvn/bin/sv
> > nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
> > acentos/In
> > ?\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
> > server).
> > Check out fails.
> > Oh, my God.
> >
> > Suggestions ?
>
> First, avoid non-ascii characters in file names.
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
Yes!
> 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
> wackiness?
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
convention again?
What are doing my Czech, German and Turk friends in this forum?
Received on 2012-02-02 08:38:33 CET