I noticed that the FAQ and other docs are heavily biased towards the
Apache "WebDAV" configuration. For example:
>The long answer: if you just want to access a repository, then you only
>need to build a Subversion client. If you want to host a networked
>repository, then you either need to set up Apache2 or use our standalone
>server process over ssh.
First, I'd like to say that Apache is a complicated piece of software
to configure, let alone compile from source codes. When I first started
reading quotes like "Don't worry, you can run Apache 2.0 on a different
port, while continuing to run Apache 1.x on port 80" I almost fell out
of my chair. That's stuff that nerds would do, it's not stuff you suggest
as a first approach to a general audience. I should qualify this by
saying that I have personally patched and compiled and configured
Apache before. But it takes a lot of time, and you have to understand
a lot of complicated details if you want to do it right, and you have
to be very interested in web server features.
I'm not interested in that. I just want version control that doesn't
suck. So I took one look at the WebDAV and was like "Yeah right, let's
go for ssh tunnel." SSH is itself a separate system with its own
concepts, but at least it's an order of magnitude simpler than Apache.
So I built everything and set up SSH and installed TortoiseSVN, and
solved a bunch of problems with TortoisePlink not talking to the
Pageant key server that I got from somewhere else, etc. etc.
And when that was all working, I discovered a new problem: The
tunneled svn commands are running with the user account permissions,
which means the Berkeley database files need writeable group flags
or some such. This completely defeats the svn permissions, since e.g.
a user could just copy the entire Berkeley database directly. And
so I found some docs about writing setuid wrappers for the svn
But then I stumbled onto svnserve. This probably makes me sound stupid,
since it's sitting there in full view. But I'm new to Subversion and
was trying to get something testable online as fast as possible, and
so I didn't study my options in much depth. But it turns out that
svnserve works great! You just give it a list of usernames and passwords
and a chroot folder, and it handles the rest, with no need for apache
or SSH or even user accounts on the server.
The reason I'm mentioning this is that the Subversion project is
lacking users right now, and maybe this is because of a perception
that it's hard to install. For example, if I was not as comfortable
with Linux, I might have given up when I saw that crap about
installing multiple systems and possibly recompiling apache.
So, my suggestion is to tout WebDAV and SSH tunnelling in some kind
of "Sexy Advanced Configurations" appendix, and focus the documentation
on svnserve. If I could go back in time, I would tell myself...
svnserve -d -r /var/lib/svn &
It would have saved me hours...
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 15 03:02:59 2004