top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

svn 1.8.1 fails on underscore in the tunnel protocol

+1 vote
397 views

We have a custom tunnel protocol with repository URLs of the form:

 svn+foo_bar://

After upgrading from svn 1.7.x to 1.8.1, these URLs are considered invalid, giving an error of:

svn: E170000: Illegal repository URL

This occurs on an 'svn up' or an 'svn checkout'. Changing the tunnel protocol name to 'foobar' (i.e. drop the underscore) appears to work properly, both 'svn up' and 'svn checkout' work fine.

posted Aug 16, 2013 by Sonu Jindal

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
 
Best answer

Check section 3.1:

http://www.ietf.org/rfc/rfc3986.txt

Underscores are not allowed in the URL scheme. It would appear that allowing them was a bug in previous versions of Subversion.

answer Aug 16, 2013 by Dewang Chaudhary
Similar Questions
+1 vote

I am running subversion 1.4.2 server with apache 2.2.14 on Linux machine. Now I want to upgrade to subversion 1.8.8 with apache 2.2.25 . Please guide me how to upgrade?

+1 vote

I recently upgraded my Subversion client from version 1.7.5 to 1.8.3 and from that time on I experience hangs when executing multiple 'svn log' commands in a short amount of time. The "hanging" svn process consumes all CPU cycles it gets but never finishes.

I can reproduce the problem using the following shell script (on Windows using Cygwin):

#!/bin/bash
ROOT="http://example.com/svn/trunk"
for DIR in $(svn ls "${ROOT}" | head -n 4); do
 svn log -v -l 5 "${ROOT}/${DIR}" 2>&1 | head -n 100 > /dev/null
done

In my environment I need at least 4 svn processes to achieve the faulty behavior. The hang only occurs if the output is truncated using the head command (but it can be redirected to a normal file instead of /dev/null which then contains the expected log messages).

+2 votes

While merging branch back to trunk I constantly get the error in the subject. Note that x/y/z has svn:mergeinfo property. The property was not added on the branch, but it was already there when the branch was created. Subsequently x/y/z is deleted on branch.

The error is generated when running: "svn merge ^/branches/mybranch" on a trunk working copy.

Sounds to me like a bug, svn tries to update the mergeinfo on the deleted path. Is that so ?

+1 vote

In attempts to build the gomp_4.0 branch from svn (on CentOS 6.2), I find that I must remove the -Werror option in STRICT_WARN. I don't find documented how this should be done (in configure ?). I can get past it by repeatedly modifying gcc/Makefile, but this seems wrong.
I have little interest at this stage in finding out why it triggers -Werror=maybe-uninitialized in typeck.c; I'd only like to build the gcc to see if it does anything interesting with OpenMP 4.

+2 votes

I updated my Server from Apache 2.2 to Apache 2.4 ( windows binaries from apachehaus on Windows Server 2008 x86)

The configuration is the same. Only the necessary syntax changes were made.

I have a test repository with the same content over the past 8 years. Before and after each change of a configuration I measure the time consumed for checking out this repository.

The old configuration with Apache 2.2 and SVN 1.8.11 needed 22 seconds. With Apache 2.4 it lasts about 180 seconds.

Does anybody have an idea what has changed or what has to be changed?

...