Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Setup An SVN Repository server



On Tue, Jan 28, 2014 at 11:20 AM, Edward Ned Harvey (blu) <blu at nedharvey.com
> wrote:

> > From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> > bounces+blu=nedharvey.com at blu.org] On Behalf Of John Malloy
> >
> > Does anyone have suggestions on the best way to Setup An SVN Repository
> > server?
> >
> > Are there templates out there?
> >
> > Is this a fairly simple build?
> >
> > What distro & tools are best?
>
> Your basic choices will be to use http/https, ssh, or svnserve.
> svnserve is the simplest, easiest to setup, highest performance, but also
> the least secure.  I recommend svnserve if you're going to have the server
> only available on a private LAN, and not otherwise.
>
>
I recommend HTTP(S) because invariably, you'll have some users (e.g.
Documentation team) who want to use an svn client that doesn't support
svn+ssh. Besides that, you get the benefit of setting up a repo browser
once you have Apache running.  I've done benchmarks for my clients, and
although HTTP obviously adds overhead, the difference was not that great
even compared to straight file:/// protocol access.


> If you're going to grant ssh to the server anyway, then you might as well
> do svn over ssh.  If you *don't* want to grant ssh access to the machine,
> then you're probably better off going with http/https.
>
> http/https are the most complex to set up, and the least performant, but
> the most secure and the most robust.  You can lock down permissions on a
> per-directory basis, you can authenticate using any mechanism under the
> sun, you can SSL encrypt and make it securely exposed to the internet at
> large.  I recommend going this direction if these characteristics are a
> requirement for you, and I recommend the other simpler options if you don't
> need these features.
>
> It's true that things like collabnet svn edge (and other basically
> appliance type distributions) will simplify installation and deployment for
> you.  But the downside of that is, you learn nothing, and hence, when you
> need to modify or tweak something, it's kind of beyond your control or
> outside of your scope.  So make up your mind, if you want to thoroughly
> read the subversion book (available for free reading on redbean) and roll
> your own...  Or go with one of these canned solutions, and hope you don't
> need to know any more about it...


I don't think it's an either/or decision with your choice to use an
"appliance" like CollabNet Subversion Edge v. roll-your-own.  You can roll
your own and you'll be required to know what you're doing and/or learn as
you go.  You can use the appliance and you'll get started more quickly.
 Either way, I'd strongly encourage you to read the RedBean book because it
will give you the necessary background on how the appliance works.  And,
there is nothing proprietary about the appliance that would prevent you
from migrating to a "custom" roll-your-own setup later.  The only caveat
that I'd mention with CollabNet is that it only works with the built-in
user management system, or LDAP.  It doesn't provide a way to configure
external auth. They 'advertise' an API, but it's severely limited.  For
example, you can't read users from their API.

Greg Rundlett
http://eQuality-Tech.com <http://equality-tech.com/>
http://freephile.org



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org