[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: Ryan Schmidt <subversion-2006q2_at_ryandesign.com>
Date: 2006-06-15 10:39:10 CEST

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

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
Received on Thu Jun 15 10:41:14 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.