Molle Bestefich <molle.bestefich@gmail.com> writes:
> 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?
No (not currently, anyway, although this should not be taken as a
statement one way or another about CollabNet's future plans -- there,
wasn't that helpful? :-) ).
However, there are sources of paid support for Subversion, and if you
go to http://www.collab.net/subversion/ you can get a list.
-Karl
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 29 02:32:44 2004