Ian Bicking: the old part of his blog

Subversion Maintenance

Subversion has been kind of a pain in the ass; I'm constantly having to run svnadmin recover (or worse). I blame it mostly on the Berkeley database. It's contantly crapping out when there's concurrent access. ViewCVS has to have write access to the repository. Permissions get messed up. It sucks.

Anyway, as a result I've turned off ViewCVS for the svn://colorstudy.com repository. Instead, the repository is browseable at http://colorstudy.com/svn/. If you want history or anything, you'll have to use the subversion client.

To do it, I added this to my hooks/post-commit script:

touch /var/lib/subversion/update.txt
chmod a+w /var/lib/subversion/update.txt
And run this script via a cronjob:
#!/bin/sh

FILE=/var/lib/subversion/update.txt

if [ -e $FILE ] ; then
    rm -f $FILE
    cd /www/colorstudy.com/html/svn
    svn up
fi
And add this to my Apache httpd.conf:
<Directory /www/colorstudy.com/html/svn>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  DirectoryIndex
  DefaultType text/plain
  AddType text/plain .cgi .py .php
  AddType text/html .shtml
  RemoveHandler .cgi .php .php3 .py .pl
</Directory>

At work we're using ssh to access the repositories. This causes constant permission problems, as a user writes the files as themself, leading to situations where the files aren't writable by others. Neither umask or the sticky bit on the db/ directory seem to fix it reliably. So, I added this line to the end of hooks/post-commit:

cd /path/to/repository/db && chmod g+w *
There's been some infrequent problems due to concurrent access since then, but no permission problems.
Created 27 Oct '04
Modified 14 Dec '04

Comments:

svn 1.1 supports something called 'fsfs', the file system file system. It's non Berkeley DB storage for svn. Seems like it could be less flaky. Take care.
# John P Speno

Have you played with Trac at all? It's an excellent Web-based wiki/bug tracker/Subversion repository viewer. We've been using the heck out of it and love it.

It was flaky with Subversion at first, but we managed to fix the problem.
# Adrian Holovaty

I think you would like arch: www.gnuarch.org
the archive maintenance doesn't even exist!
# rastandy

I once kept one project in Arch, but repository was broken so badly, that I could come round with it.

So I was forced to abandon this crashy system.

# Michal

Just curious, but does the RSS pubdate get bumped to NOW() for each comment? The feed showed up as new a few times but I didn't notice a difference in content. Of course, I'll know in a second after I submit this and check the feed again ...
# Jack Diederich

I battled with permission problems with Subversion ssh access for months until I finally nailed it down: set the umask to 002 in /etc/bash.bashrc --
http://mg.pov.lt/blog/setting-umask-for-subversion.html contains the full story.

ViewCVS also used to cause occasional problems that disappeared once we added a robots.txt file kindly asking search engines not to hammer our repository.

BTW I like your post-commit hook + cron job solution for getting a reasonably up-to-date checkout.

Off-topic: a Preview button in the add new comment form would be nice.
# Marius Gedminas

Re: fsfs; I certainly look forward to it. I think by now everyone is pretty aware of bdb's shortcomings for Subversion. You live, you learn.

Re: Trac; I haven't tried it. I've heard it has caused problems similar to what viewcvs has caused. But, if it communicates with the subversion server as a client, I imagine it would work well -- if not, then it'll have the same problems as viewcvs. (There is supposed to be some experimental viewcvs code that uses the client interface, which would also fix things). It sucks to give write access to web clients, but apparently that requirement is bdb's fault.

Re: arch; I dunno... the technical arguments for it don't hold a lot of sway with me. There's an article that I can never find when I want it, which I think very successfully defends the advantages of a centralized repository. Basically the claim is that distributed repositories are necessary only for a very small number of projects (like the Linux Kernel), and are detrimental to most open source projects, where centralization provides transparency. What I've seen of arch also seems rather arcane; reminds me of qmail a little, in that the author made up all sorts of weird conventions. But I dunno, maybe.

Re: RSS; I was having problems posting this last article. It's probably an anomoly.

Re: bashrc; dammit, why are there so many rc scripts for the shell? I can never keep track of them all, or which ones get called in favor of others. Anyway, the post-commit chmod trick is working for now.
# Ian Bicking

A better choise for a web interface for svn is http://websvn.tigris.org/

It uses the svn client to access stuff and doesnt need write access to the repository. Here at work we've been using SVN with websvn since january and we've only had to run recover on the repository once.

Also unlike cvs you can quite successfully run svn up from within the post-commit script itself with no problems, we keep our devel site up to date that way, whenever a commit made, it checks which repository dir was in then runs an svn update on the appropriate devel dir.
# Adam Ashley

If you're running Apache2, i advise you setting up webdav access to your SVN repository. I believe it's the best way to display the last revision of your respoitory.

# phil

$ cat `which svnserve`
#!/bin/sh

SVNSERVE=$(dirname $(realpath $0))/svnserve.bin

umask 002
$SVNSERVE "$@"
#

If you are mixing local/ssh and webdav access, you will need to change the umask with which apache runs, either using mod_umask or simply adding the line to the apache2ctl script.
# anonymous

And using svn + https has another feature, you don't use SSH, so you have to fight with the umask. On the other side, apache need to write stuffs in the SVN so ..
# Jkx