echo "hey, it works" > /dev/null

just enough to be dangerous

zsh completion broken for svn 1.5


Someone updated subversion to 1.5 on the dev server (Red Hat 4.3.0-8) this morning, and consequently broke my zsh tab completion.

% svn add[TAB]
_arguments:comparguments:303: invalid argument: ARG

This bug report for Ubuntu describes the same problem, and the fix works for me, except that the file to edit (replacing "/ arg/:arg:" with "/ (arg|ARG)/:arg:") is located in /usr/share/zsh/4.3.4/functions/_subversion.

Update:

If you're on a system where you don't have privileges to write to /usr/share/zsh and the system admins are too retarded (sorry, "don't have the resources") to apply a patch that changes two lines, you can override the subversion completion like this:

mkdir ~/zsh
cd ~/zsh
wget http://gvn.googlecode.com/svn/trunk/contrib/zsh/_subversion

Then include the directory in your $fpath by placing the following in your .zshrc:

fpath=(~/bin/zsh $fpath)

Of course, ~/zsh is arbitrary, put it wherever you like.

Subversion tricks


I've been mucking around with subversion a bit lately. It's all pretty dreary stuff, but if I don't write it down I'll forget it.

First, there are three projects I'm working on at the moment that make use of other open source software, so to avoid whacking someone else's code into my repo, I've set up some svn:externals. A succinct explanation of setting up externals can be found here.

One of those open source projects I'm using is the Zend GData library, which I use to interact with YouTube from a Habari plugin. One pain is that svn:externals can only externalise directories, but the GData library has the class files in a directory all together and support code in per service directories. Therefore, I've got to include the whole thing just to use YouTube. Bummer.

Second, a couple of things crossed my radar related to hooks, so I thought I'd have a play. I used this article about checking PHP syntax on commit as a starting point, and hacked up a quick check on the commit log for habari-extras to make sure that the entry starts with "plugin" or "theme" so that committers remember to identify what they're committing to. It probably won't get used, but it was interesting. The thread discussing it is here

Setting up a subversion repository in /


I've been using subversion for all my versioning needs for a while now, but I've always either used existing repositories or set the repository up in a user account. I'd like to give other local users the ability to commit to some of the projects I'm working on, so I've been trying to set up a subversion repository in the directory root. After a number of false starts, I've got what I think is a sensible solution. I'll document the false starts and the solution here.

I created a group called svn, and I'll add anyone who I want to give commit access to that group. Subversion needs to create the repository directory, so I started off with

% svnadmin create /svn
svnadmin: Repository creation failed
svnadmin: Could not create top-level directory
svnadmin: Can't create directory '/svn': Permission denied

Of course, I'm not logged in as root, so svnadmin doesn't have permission to create the directory. I always do this, because I'm a dill, which means I use the bang bang history substitution regularly.

% sudo !!
svnadmin create /svn

This runs the last command with sudo, and successfully creates the repository.

% ls -dl /svn
drwxr-xr-x  7 root  wheel  512 Nov 15 14:13 /svn/

The repository and all the files and directories inside it are owned by user root in group wheel. That's not good, because I want normal users to be able to write to the repository. I could change all the ownership and permissions of files and directories using a couple of find commands but that feels wrong.

Then Donal reminded me that each project should have it's own repository. This is because when a commit is made the repository revision is incremented, rather than the committed files revision. So, what I should do is to create a top-level directory that will hold the repositories, then create a repository for each project inside that.

First, set up the directory that will hold the repositories, ensuring it has correct ownership and permissions.

% sudo mkdir /svn
% sudo chgrp svn /svn
% sudo chmod 775 /svn

Next, create a repository inside that directory. I'm working on my first theme for Habari, so I'll create a repository for that work.

% svnadmin create /svn/habari

There are a number of different ways to get your project into your repository. I prefer to check out revision 0 and add my work to it.

% svn checkout file:///svn/habari
Checked out revision 0.
% cd habari
% cp -r /usr/local/www/habari/htdocs/user/themes/connections/habari/ .
% svn add themes
(output omitted)
% svn commit
(output omitted)

Now I have a shared repository that (hopefully, but untested) members of the svn group can checkout and commit to. Of course there's a better way, please let me know.