Re: request for input: possible move to SVN

On Oct 27, 2004, at 20:56, Jacob Smullyan:

> I have been using subversion for my own projects lately, and much
> prefer it to CVS.  In particular, the ease with which files can be
> moved and branches maintained, as well as the noticeable performance
> improvements, make it to my mind a clear win.
>
> ...
>
> What do you think?

I am not a developer on the SkunkWeb project, but I have to concur with  
Jacob's assessment of Subversion. We've used it for two major projects  
and found it to be an acceptable alternative to many revision control  
systems (and vastly superior to CVS).

For us, there were two areas of major concern when switching from our  
expensive commercial solution (which will remain unnamed). The first  
was performance in a medium-sized project (eight developers). The  
second was data integrity. Being that Subversion was relatively new  
(and Berkeley DBs -- the underlying data storage mechanism for  
Subversion repositories -- are relatively fragile), we were tentative  
to try it for a new project.

It turns out our fears were somewhat justified. We chose to access our  
subversion repositories via mod_svn and Apache 2.0. Although the  
web-browsing aspect was kind of sexy, performance seemed much slower  
compared to what we were used to with our other revision control  
system. Second, the repository frequently became "wedged" and we needed  
to halt Apache and issue "svnadmin recover" commands to recover (so  
much so that we made a cron job to do this every 8-12 hours).

However, rather than abandoning Subversion altogether, we decided to  
play around with the configuration to see if we could make it an  
acceptable alternative. The first thing we did was to get rid of Apache  
2.0 and mod_svn. Instead we chose to access our repositories via  
svn+ssh://.... Although this required careful planning of  
groups/permissions and also necessitated that each developer had a  
login on the repository machine*, such requirements were not  
prohibitive in our case. Immediately, we noticed a speedup in checkouts  
and commits. We also noticed that repository hardly ever got in the  
"wedged" state we experienced so frequently with mod_svn. For those who  
wanted continued web access, we used ViewCVS  
(<http://viewcvs.sourceforge.net/>) which added support for Subversion  
a while ago and is actually much nicer than the mod_svn web interface.

In anticipation of the handful of times the repository did become  
corrupt, we modified the hot-backup.py script that accompanies many  
Subversion installations and installed it as a post-commit hook** (see  
<http://svnbook.red-bean.com/svnbook-1.0/ch05s03.html#svn-ch-5-sect 
-3.6>). We also had a nightly script that did incremental dumps from  
the repository in the event that we needed to upgrade Subversion and  
reload (that way we wouldn't have to dump the entire thing and could do  
a quick upgrade by dumping only those new revisions not covered by the  
previous night's backup).

I've attached our svnbackup script*** for reference. We called it in a  
cron job as follows (this is only for reference, check your version of  
cron to see if/how it supports commands which span multiple lines):

     30 23 * * 0     "${HOME}/bin/svnbackup" -d -j -r 0  
"${HOME}/svnroot" \
         "${HOME}/svnbackup"
     30 23 * * 1-6   "${HOME}/bin/svnbackup" -j -l "$(date +\%w)" -r 0 \
         "${HOME}/svnroot" "${HOME}/svnbackup"

This used the attached script to create weekly complete backups with  
daily incrementals.

If anyone has any questions regarding our experience with Subversion,  
please feel free to ask. I'd be more than happy to share additional  
details as requested. I hope this helps!

Matthew Bogosian
President/COO, Arena Unlimited, Inc.
http://arenaunlimited.com/

Notes:

* Alternatively, one could create one single user on the repository  
machine for each repository and allow users to log in as that user  
(e.g., via ~reposuser/.ssh/authorized_keys). That way, instead of each  
developer using their own logins for svn commands, everyone uses the  
same user:

     svn co svn+ssh://reposuser@svnhost/path/to/repos

You have to trust your developers not to log in as that user and do  
stupid things (like delete the repository), but for most teams with  
which I've been involved, this has never been an issue. If you suffer  
from OCD (as most good admins do), you can have the repository user's  
home directory and the repository itself owned by "nobody" or something  
(so that it's read-only), and only give write access to the  
repository's db directory to that user's group. Your mileage may very,  
but I encourage you to experiment. This still allows users to delete  
the repository, but narrows the field of potential destruction.

Another alternative (if you have root access to the repository machine  
or are allowed to run daemons) is to run svnserve in either inetd or  
daemon mode. For SSL, one can either use the SSL-patched version of  
svnserve, or one wrap it in an SSL connection with stunnel or ssh. See  
the svnserve man page or  
<http://contactor.se/~dast/svnusers/archive-2004-10/0119.shtml> for  
details.

** Warning: hot-backup.py is pretty CPU and disk intensive for larger  
repositories. The speed of Subversion operations tend to suffer  
immediately following a commit as a result. They don't fail, they just  
take a little longer to execute. For example, for those of use who  
liked to do "svn commit ... && svn update ...", our update took a  
little longer because the repository machine was still busy doing the  
hot backup. Another (or faster) CPU, a faster disk (or RAID), more RAM,  
etc. in the repository machine may make this negligible.

*** This script requires a posix-compatible environment with Bash  
version >= 2 installed as /bin/sh (it needs the getopt shell built-in).  
If you have bash2 installed elsewhere modify the first line to point to  
that installation. If you run it without any arguments, it will give  
man-page like instructions on its usage.