FYI, problem #5 was solved by switching from BDB to FSFS.
Now we can checkout binary files at an astonishing 109 kB/s :-).
The aforementioned problem was the last actual show-stopper
encountered with our SVN installation. The installation seems stable
and it looks like this might be this SCM tool that we'll stick to.
Just out of interest, does CollabNet sell support on SubVersion?
On Tue, 26 Oct 2004 19:06:25 +0200, Molle Bestefich
<molle.bestefich@gmail.com> wrote:
> 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:
>
> > > a.)
> > > 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?)
>
>
> > > b.)
> > > 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.
>
> > > c.)
> > > 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 [6.] 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 Dec 21 20:25:44 2004