These forums are read-only!
SVN...
  • Elliott HirdElliott Hird
    My experience with SVN:
    1. svnserve plain - Two words: Plaintext. Passwords.
    2. svnserve+ssh - "You want to expose something other than your whole filesystem? LOL!!!112121121"
    3. mod_dav_svn - Apache + 256slice = no no no no no no no no

    Anybody have suggestions?
  • kal
    I am currently using method #3. It all depends on how busy your svn server (personal or a few developers) will be. With reasonable apache params, you can certainly run it on a 256 slice.

    Here is my free under normal load:


    [~] % free -m
                 total       used       free     shared    buffers     cached
    Mem:           254        248          5          0         31         51
    -/+ buffers/cache:        166         88
    Swap:          511         28        483
  • Elliott HirdElliott Hird
    I'm going to be running nginx+mongrel cluster and trac on here too. I don't think that's enough to fit apache in JUST for svn.
  • mattmatt
    We're dabbling with an optional SVN service for customers. It makes sense because a lot of folks here use it, so we shouldn't make everyone set it up. Thoughts on what would be appealing to you: disk space, access, etc?
  • Elliott HirdElliott Hird
    matt: That'd be pretty cool, although I can't say I'd use it as I like control. Disk space doesn't really matter much for SVN as code is small, generally. Just give them access to the standard options of svnserve.conf - I've seen too many SVN servers that push exactly their config to you, and you can't change it.

    For me, I just went the normal svnserve route. If someone can see that file, they can already remove all my stuff anyway.
  • al3xal3x
    Matt: that would definitely be appreciated. Better yet would be something like "DevjaVu":http://www.devjavu.com/'s offering that includes both svn and Trac.

    Elliot: My setup here on Slicehost is a commingling of svn+ssh and mod_dav_svn. I use the former to maintain my various projects for myself, and the latter to make them publicly available (with granular access control). "http://code.al3x.net/":http://code.al3x.net/ is running on httpd with mod_dav_svn behind nginx, in addition to two Mongrel clusters, all listening for different domains and subdomains.

    Throwing Trac into the mix, however, is not something I've ventured.
  • Elliott HirdElliott Hird
    http://code.elliotthird.org/ <-- One tracd bound to 127.0.0.1 being proxied via nginx, and going to a plain svnserve server. Works quite well.<br />
    (leave it alone)
  • mattmatt
    I'm not a big trac fan. And collaboa was kind of tricky to setup.
  • Elliott HirdElliott Hird
    I'm not a fan either, but it's the best avaliable.
  • slamb

    Elliot:

    svnserve+ssh - "You want to expose something other than your whole filesystem? LOL!!!112121121"

    You can lock down access so that ssh can only be used to run svnserve. Read here.

  • tomislav
    Bah, who needs Subversion when you have bazaar-ng ;)
  • matid
    I think I'll be going for svnserve proxied by lighttpd for anonymous access and svnserve-restriced svn+ssh for write access. Sounds like a reasonable and quite secure solution for me.
  • Elliott HirdElliott Hird
    darcs is awesome.

    'nuff said.
  • dirtymafia
    +1 for svn access. I'm sure storage isn't a big issue, most of my projects anyway are quite small. But it would be nice to get it off my slice.
  • Arachnid
    I've run Apache on a 256MB VPS (not Slicehost - a previous server) with a big-ish (~60k hits/day) site (with some fairly heavyweight PHP and SQL queries, too) without any significant issues. One thing to bear in mind is that Apache uses less memory than you think - if you have one parent process and half a dozen children all reporting in at, say, 40MB, that's not much more than 40MB ram actually used - most of that is copy-on-write memory shared between all the Apache processes.
  • jmelby
    As an alternative to trac... I've been using this and like it a lot:

    http://retrospectiva.org/
  • alex
    just see no point in providing svn access. what next, shared hosting?
    do what you do best, provide slices and KISS.
Add a Comment