[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems with svn client tools

From: Johan Appelgren <johan.appelgren_at_gmail.com>
Date: 2006-06-14 12:28:27 CEST

On 6/14/06, Peter Fastré <peter.fastre@gmail.com> wrote:
> Thanks for your reply.
>
> I don't know why I was using BerkeleyDB, I guess I've read it somewhere in
> an outdated manual. I'll convert them to FSFS.
>
> I think the problem is indeed locale related. I've tried some things, but
> don't get to a solution.
>
> First of all, I updated the c-libraries and the shell (bash is now version
> 3.1.17(2)-release). With no result, however the other system (which is
> working fine) uses an older version of bash (2.05b.0(1)-release) so it's a
> difference which could be the cause of our problems.
>
> I've read this:
> http://svnbook.red-bean.com/nightly/en/svn.advanced.l10n.html,
> which gives us some general information, but not enough to solve my
> problems.
> When I set the locale to en_US.utf8, I get following messages:
> root@smith:/data/svn/_scripts# locale
> LANG=en_US.utf8
> LC_CTYPE="en_US.utf8"
> LC_NUMERIC="en_US.utf8"
> LC_TIME="en_US.utf8"
> LC_COLLATE="en_US.utf8"
> LC_MONETARY="en_US.utf8"
> LC_MESSAGES="en_US.utf8"
> LC_PAPER="en_US.utf8"
> LC_NAME="en_US.utf8"
> LC_ADDRESS="en_US.utf8"
> LC_TELEPHONE="en_US.utf8"
> LC_MEASUREMENT="en_US.utf8"
> LC_IDENTIFICATION="en_US.utf8"
> LC_ALL=en_US.utf8
> root@smith:/data/svn/_scripts# svn mkdir
> file:///data/svn/newrepos2/tags3 -m "test"
> svn: Valid UTF-8 data
> (hex:)
> followed by invalid UTF-8 sequence
> (hex: c0 85 01)
>
> The folder is created, though.
> When I set the LC-vars to the default C, I get the following:
> root@smith:~# locale
> LANG=en_US
> LC_CTYPE="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_COLLATE="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_PAPER="C"
> LC_NAME="C"
> LC_ADDRESS="C"
> LC_TELEPHONE="C"
> LC_MEASUREMENT="C"
> LC_IDENTIFICATION="C"
> LC_ALL=C
> root_at_smith:~# svn mkdir file:///data/svn/newrepos1/trunk7
> -m "test"
> svn: Can't convert string from native encoding to 'UTF-8':
> svn: ?\192?\133
>
> If I set the locale to en_US, I get the following:
> root@smith:~# locale
> LANG=en_US
> LC_CTYPE="en_US"
> LC_NUMERIC="en_US"
> LC_TIME="en_US"
> LC_COLLATE="en_US"
> LC_MONETARY="en_US"
> LC_MESSAGES="en_US"
> LC_PAPER="en_US"
> LC_NAME="en_US"
> LC_ADDRESS="en_US"
> LC_TELEPHONE="en_US"
> LC_MEASUREMENT="en_US"
> LC_IDENTIFICATION="en_US"
> LC_ALL=en_US
> root_at_smith:~# svn mkdir file:///data/svn/newrepos1/trunk243
> -m "test"
> svn: Can't open directory
> '/data/svn/newrepos1/db/transactions/13-2.txn/Ŕ
>
> ': No such file or directory
>
> Now I understand that svn has to convert the filenames I write on the
> commandline to utf8. But problems should only occur when using special
> characters like "éŕ..., wouldn't you think?
>
> This thing is driving me crazy by now. I'm using a lot of things on linux,
> but never ran into something like this. I hope someone can help me out here.
> I still think it's very strange, because via webdav everything is working
> great...
>
> I'd like to end this long mail (thanks for reading!) with a funny note:
> root@smith:/data/svn/_scripts# svnlook diff /data/svn/newrepos2
> Segmentation fault
>
>
>
>
> On 6/13/06, Kevin Grover <kogrover@yahoo.com> wrote:
> >
> >
> >
> >
> > Sounds like you may have you're locale set to a non-English locale AND
> your terminal program can't handle it. Get a better terminal program, or
> set the locale to an English one (to get all messages in English).
> >
> > Also, if you're running into cleanup/lock problems, you are probable using
> a BDB backend. You should really consider converting to the FSFS backend.
> FSFS is the default in all recent versions of Subversion.
> >
> > It's easy to convert
> >
> > # WIth OLD svn client:
> > svnadmin dump path-to-repo >repo.dump
> >
> > # With NEW svn client:
> > cd /path/to/new
> > mkdir repo
> > svnadmin create repo
> > svnadmin load repo <path/to/repo.dump

Problems on the client side with working copies getting locked and so
on will not be solved by changing to FSFS. If BDB works fine for
someone, why recommend that they switch when they're having client
side issues? Is there some major performance or other advantage when
using FSFS that I've missed?

/Johan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 14 12:30:30 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.