Problems with svn client tools

[Peter Fastré <pe...@gmail.com>]

ello

I've setup a slackware server with svn - apache - trac. Some things are
working great, server can be accessed using svn on a windows system and
tortoiseSVN on another windows system.
However, when I try to use the command line utilities on the server
itself, I keep having strange problems.
For example, when I try to do this:
peter@smith:~/www/earli$ svn status
? ìG
L .
!M pdf.php
! project
!M earli.zpj

I see those strange characters.
I tried to do an svn update, but got a 'Segmentation fault'. After
that, I got this:
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

Which sounds reasonable. So I do a cleanup, but then I get this:
svn: Can't open directory 'project/layouts/earli/img/.svn/tmp/ðR': No
such file or directory
Another strange character!

The same repository works great from trac (running on that server),
from svn on another slackware server (with same slackware version!
10.1), and tortoisesvn on a windows client.

Maybe it has something to do with unicode support of my console or
something?

Another problem, maybe related is:
root@smith:/home/peter/www/earli# svnlook diff /data/svn/earli
Added: trunk/framework
===================================================================
svnlook: Can't read file '/tmp/svnlook.23/trunk/framework.tmp': End of
file found

But the file /tmp/svnlook.23/trunk/framework.tmp does exist!

I searched on the internet, in the newsgroups, mailing lists, but
really
can't find an answer. I really hope someone can give me a clue???

Regards
Peter

Re: Problems with svn client tools

[Peter Fastré <pe...@gmail.com>]

On 6/15/06, Ryan Schmidt <su...@ryandesign.com> wrote:
>
> But the point is I do not get a segmentation fault. I am using
> Subversion 1.3.2.


I think svnlook diff command is supposed to give us the differences between
the latest and the previous revision. However, if I pass a specific revision
to compare on the command line, I get the same segmentation fault.
It does have something to do

It would possibly help to know what version of Subversion you're
> using and how you installed it. I probably wouldn't know what to do
> if you answered those questions, other than to say "get Subversion
> 1.3.2" if you're using anything earlier, and "install it again, or in
> a different way." The behavior you're seeing is weird and I don't
> recall seeing anything like that in 18 months on this list, so I
> think something is strangely broken in your setup and perhaps
> installing Subversion in a different way (use a different binary
> package, or build it from source?) would correct the problem.


I built version 1.3.2 from source, as I do with most of my applications:
 $ ./configure --with-swig --with-apxs=/usr/local/apache2/bin/apxs
--with-apr=/usr/local/apache2/bin/apr-config
 --with-apr-util=/usr/local/apr/bin/apu-config

I have tried recompiling it, removing everything, recompile and install. But
no help here.

The apr/apxs/... are needed by apache, the with-swigs are the python
bindings which are needed by the trac application. Both apache and trac are
working fine.

But there's something really wrong with my setup and I don't know what. I
would do anything to solve it, reinstalling the whole svn-thing, I don't
know. The only option which cannot be considered is reinstalling the
complete machine. Maybe I'm doing something wrong in my build process?

Regards

Peter

Re: Problems with svn client tools

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 14, 2006, at 11:19, Peter Fastré wrote:

> 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@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?

Yeah, and "À" is a special character. But why is it trying to access  
a directory called "À" in the transaction directory? I don't know  
exactly what Subversion usually does with those directories (since  
the transaction directories are around for such a short length of  
time that it's virtually impossible to get a look into them), but  
this sounds odd. Sounds just as odd as what you showed us before:

On Jun 13, 2006, at 12:11, Peter Fastré wrote:

> So I do a cleanup, but then I get this:
> svn: Can't open directory 'project/layouts/earli/img/.svn/tmp/ðR': No
> such file or directory

Don't know what a directory "ðR" is meant to be doing in .svn/tmp  
unless you're intending to have a directory by that name in the  
working copy, which it sounds like you're not.


> 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

And that of course should not happen either. Um... is that the actual  
command you used? Because it doesn't look to me like you've told it  
what to compare to what. Though I was surprised when I ran "svnlook  
diff <repopath>" on my repo that it produced a diff. I'm not sure  
what revisions the diff was between. Does it show the difference  
between the revision prior to HEAD, and HEAD? The documentation isn't  
telling me. As far as I recall, I always told "svnlook diff" the two  
revisions between which I wanted a diff.

If the repository does not exist, my "svnlook diff" produces this  
message:

svnlook: Can't open file '/data/svn/newrepos2/format': No such file  
or directory

If the repository exists but is empty, I get this cute message:

svnlook: Transaction '(null)' is not based on a revision; how odd

But the point is I do not get a segmentation fault. I am using  
Subversion 1.3.2.

It would possibly help to know what version of Subversion you're  
using and how you installed it. I probably wouldn't know what to do  
if you answered those questions, other than to say "get Subversion  
1.3.2" if you're using anything earlier, and "install it again, or in  
a different way." The behavior you're seeing is weird and I don't  
recall seeing anything like that in 18 months on this list, so I  
think something is strangely broken in your setup and perhaps  
installing Subversion in a different way (use a different binary  
package, or build it from source?) would correct the problem.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Problems with svn client tools

[Nico Kadel-Garcia <nk...@comcast.net>]

Johan Appelgren wrote:

> 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?

FSFS is cross-platform compatible. The authors of BDB just had their company 
purchased by Oracle, so the gods alone know what will happen to the 
technology, but I strongly suspect that development will suffer if not be 
dropped altogether. FSFS seems less likely to become corrupted and 
impossible to salvage from the wreckage.

But those are server side issues. 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Problems with svn client tools

[Johan Appelgren <jo...@gmail.com>]

On 6/14/06, Peter Fastré <pe...@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@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@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 <ko...@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

Re: Problems with svn client tools

[Peter Fastré <pe...@gmail.com>]

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@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@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 <ko...@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
>
> ----- Original Message ----
> From: Peter Fastré <pe...@gmail.com>
> To: users@subversion.tigris.org
> Sent: Tuesday, June 13, 2006 3:11:29 AM
> Subject: Problems with svn client tools
>
> ello
>
> I've setup a slackware server with svn - apache - trac. Some things are
> working great, server can be accessed using svn on a windows system and
> tortoiseSVN on another windows system.
> However, when I try to use the command line utilities on the server
> itself, I keep having strange problems.
> For example, when I try to do this:
> peter@smith:~/www/earli$ svn status
> ? ìG
> L .
> !M pdf.php
> ! project
> !M earli.zpj
>
> I see those strange characters.
> I tried to do an svn update, but got a 'Segmentation fault'. After
> that, I got this:
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
> Which sounds reasonable. So I do a cleanup, but then I get this:
> svn: Can't open directory 'project/layouts/earli/img/.svn/tmp/ðR': No
> such file or directory
> Another strange character!
>
> The same repository works great from trac (running on that server),
> from svn on another slackware server (with same slackware version!
> 10.1), and tortoisesvn on a windows client.
>
> Maybe it has something to do with unicode support of my console or
> something?
>
> Another problem, maybe related is:
> root@smith:/home/peter/www/earli# svnlook diff /data/svn/earli
> Added: trunk/framework
> ===================================================================
> svnlook: Can't read file '/tmp/svnlook.23/trunk/framework.tmp': End of
> file found
>
> But the file /tmp/svnlook.23/trunk/framework.tmp does exist!
>
> I searched on the internet, in the newsgroups, mailing lists, but
> really
> can't find an answer. I really hope someone can give me a clue???
>
> Regards
> Peter
>
>