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

Re: user friendly multiple repositories, how to & repo browser bug

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2004-10-26 19:06:25 CEST

On Wed, 20 Oct 2004 07:48:57 -0500, Ben Collins-Sussman
<sussman@collab.net> wrote:

> On Oct 19, 2004, at 10:03 AM, Molle Bestefich wrote:

> > 1.)
> > I have a handful of repositories set up, and I'm hunting for some sort
> > of hack to allow the Repo-Browser in TortoiseSVN to enumerate and list
> > the different repositories. Currently it returns '403 Forbidden' and
> > '450 Method Not Allowed' whenever someone forgets a trailing slash or
> > something similar, which kinda ruins the smooth end user experience.

> The TortoiseSVN repo-browser is just running 'svn ls', browsing the
> structure of a repository. There are no hacks to show all possible
> repositories. 'svn ls' requires that you point it at *one* repository.
> If you want a list of all repository URLs, you'll have to make
> yourself a web page. Maybe something CGI-based.

Ah, I see. That makes perfectly good sense, technically.
But the user experience is just awful..
Forget a trailing slash, or try and use Repo Browser to see your
company's different repositories, and you're out of luck. I know
that's not what it's designed to do, but it makes using multiple
repositories so much more a pain than just throwing everything into
one big ball, settings it up at '/' and forgetting about it, even when
multiple repositories would be much more appropriate.

Could I in theory make a PHP script (whatever) that spits out some XML
that makes the Repo Browser see the different repositories?
(Can the PHP script be called in reply to the 'PROPFIND' method? Is it
required?)

> > 2.)
> > The Repo-Browser sends duplicate "Accept-Encoding: gzip" headers.

> Hm, dunno if that's a problem, seems harmless. Still, it's a curiosity. I wonder why.

> > 3.)
> > Setting up SVN was such a sweet deal.

> You mean, 'svnserve'?

I meant the whole process.
Run the windows installer, create the repositories with 'svnadmin
create <dir>', run 'svnserve' and you're up and running. Getting
'svnserve' to run as a service took some work, if googling for 5
minutes and installing an .exe counts as work.

> > Setting up the Apache access was hell on earth.
>
> Would you like to be more specific? Is it just the error messages?

Mostly the error messages. Which I currently find vague at best,
misleading at worst. Specifics:

1. More DLL's are needed in the apache modules directory than the
Tortoise documentation,
   which is btw a rather odd location for server documentation, indicates.
   According to documentation, the files libdb42.dll, libeay32.dll and
ssleay32.dll are needed.
   That simply does not work, more DLL files from the SubVersion
directory are needed.

   What the user gets in the NT event log viewer is this:
     Syntax error on line 174 of C:/Program Files/Apache
Group/Apache2/conf/httpd.conf: .
   when in fact there is no syntax error, and:
     Cannot load C:/Program Files/Apache
Group/Apache2/modules/mod_dav_svn.so into server: The specified module
could not be found. .
   when in fact the module is right there and can easily be found.

   The Windows expert with his trusty NtFileMon will have the problem
figured out and solved in an hour or so, but pity the poor newbie.

2. In order to fix some bugs and remove the domain name from commits,
a replacement mod_auth_sspi.so is necessary, locating it takes some
Googling.

3. Any and all non-syntactic errors in httpd.conf or errors elsewhere
on the server will result in one of the two cryptic '450' or '403'
errors
   described. This includes, but I'm sure is not limited to:
    - A trailing slash too many or too few in the <Location> tag.
    - Directory name in 'Location' tag not matching last directory
name of 'SVNParentPath' directive.
    - Authentication failures
    - File access failures
    - Limitations on PROPFIND or other verbs

4. The Repo Browser seemed like a nice tool to test out if the
repositories were working while setting them up.
   Incidentally, trying to browse anything that isn't the _exact_
address of a repository will throw a cryptic '450' or '403'.
   This includes forgetting to put a trailing slash after the server
name (if sole repository at '/') or repository name.
   This is not too bad during normal usage. But during first setup,
this behaviour combined with 3.) above makes it absolutely
   impossible to figure out where one has done something wrong.

   Basically, these two cryptic error messages seems to cover just
about any server configuration error and any 'client usage error' that
one can do.

5. I'm still struggling to get svn+apache+tortoise to perform
less-than-horrible with regards to binary files.
   Checking them out in the GUI takes a good while, but I can live
with it, as long as I remember to delete old binary files from the
repository.
   Doing a 'svn export -r xx <http://<repo>/5-mb-file.exe>' takes so
long that noone here has had the patience to go through with it yet.
   After waiting for 20 minutes, most people go search for copies of
the file elsewhere.
   The server we're running SVN on is a new piece of hardware, not
really doing anything else.
   For the purpose of this test, it sits on the same network segment
as the client.
   I tried letting it run overnight, and the next morning it had
bailed out with this message:
     svn: REPORT of '/devel/install/!svn/vcc/default': Could not read
response body: An existing connection was forcibly closed by the
remote host.

Obviously, I'm not an Apache expert (yet?!). The only reason we're not
simply using svnserve is that Apache supports authentication through
our Active Directory. (And even then, the support seems spotty.. I'm
not that keen on seeing domain passwords fly over the wire to the
Apache server in practically-cleartext. hmm..)

> > Out of curiosity, why is it that it can't give proper error messages
> > instead of these awful '450 not allowed', '403 forbidden' etc. things?

> The apache server is perfectly capable of throwing human-readable
> errors and messages generated by the svn libraries, and marshalling
> them back to the client. But when the error is related merely to
> apache misconfiguration, then -- surprise, surprise -- you're going to
> see HTTP errors. It's an HTTP server, remember? :-)

That makes sense.
But if SVN is going to be used by stupid users like me, it doesn't
work that it is not more obvious what is going on.
I had a major headache after spending two whole days getting this to
work, and from Googling I see that there are many others that spend
the same painful time because of the lack of information. People need
to know what they're doing wrong, if they're to make it right. I
actually like the SubVersion way of doing things, and we're still
trying to get the last issues resolved so that we can use it as our
source management system. But this would definately not have happened
if not for the fact that I don't give up. Other, less stubborn people
will definately be more inclined to just junk it and pick something
that works out of the box, or at least is gentler on the head when
setting up..

I hope that my descriptions and comments are not too harsh, I'm just
trying to communicate clearly my points :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 26 21:39:08 2004

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

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