Please correct me if I am wrong about my understanding of mod_dav_svn, which is that it basically serves 2 purposes:
Now for point 1, are my following assumptions correct?
For point 2, if using Trac's repository browsing functionality, there is no additional use for the repository browsing functionality offered by mod_dav_svn?
Does mod_dav_svn serve any other purpose I haven't outlined here? Asked another way, is there any disadvantage to going with svnserve and Trac?
I ask because I get the impression that mod_dav_svn is very commonly used, so I wonder what I'm missing.
Forget Point #2: HTTP Browsing. That's just a slight bonus. It doesn't replace your need for something like Fisheye, ViewVC, or (my favorite) Sventon.
There are some disadvantages of using Apache's http for your Subversion server:
Then, there are advantages:
svnserve
, you can only do a single repository per instance and if you have multiple repositories on one system, you'll have to run each svnserve
process on a non-standard port.My personal take: If you are doing a corporate environment, the advantages of using the HTTP or HTTPS protocol way outweigh the disadvantages. If you are talking about a small repository and you and your friends, I run svnserve
simply because of the lower overhead and easier setup. However, in those circumstances, I just use Github and not worry about it.
I run Subversion as my personal source control system on my machine, and I use svnserve in that instance.
Thanks, some follow up questions. 1) When I access a URL on my svn server as svn://server/repo, isn't that using port 80 as well? 2) If LDAP integration can't be done for svnserve, is the only way users can authenticate is if they're in the file referred to by password-db in svnserve.conf for svn:// or have a shell account for svn+ssh://? 3) Can't the same protection offered by https:// be offered by svn+ssh://, or is there a difference? (Sorry I can't put paragraphs here it submits every time I hit enter am I doing it right.) –
It's using port 3690 by default. This can be changed when you run svnserve
, but then your svn URL has to reflect that too.
Pretty much true. Most places that use svnserve
use the passwd file. However, since version 1.5, you can use SASL. However, I have never seen anyone use it.
Yes, ssh+svn:// does offer encrypted packets. However, SSH can be tricky to implement. Basically, the svnserve process has to be spawned and run for that particular user. That means each user needs direct read/write access to the repository. You need to setup umask for each user and create a Subversion Unix group everyone belongs to. Then, since these users have direct access to the repository files, keep them from logging onto the repository server. The Online Manual has complete details. But, in the end, it only works on Unix servers and Unix clients. Windows clients don't have SSH on them, and would have to install that. I've tried it a few times, but https:// is much easier.