First, the location of AIDE+gpg in the subversion repo was “tools/AIDE+gpg” and it had one sub-directory, “trunk”. I never did end up using tags or branches or anything there. So the entire step from start to finish to do it was as follows:

git init AIDE
cd AIDE
echo "vdanen = Vincent Danen <[my email]>" >authors.txt
git svn init -T trunk svn+ssh://[repo]/tools/AIDE+gpg --no-metadata
git svn fetch -A authors.txt
git init --bare ../tmp
cd ../tmp
git symbolic-ref HEAD refs/heads/trunk
cd ../AIDE
git remote add bare ../tmp
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare
cd ../tmp
git branch -a
git branch -m trunk master
mv tmp AIDE+gpg.git

Presto. Done. Apparently I should now put this repo somewhere public (like github). I will figure that part out after lunch.

ah_post_send (#0), code is 401 (want 401), WWW-Authenticate is Negotiate, Basic realm="Kerberos Login"
auth: Got challenge (code 401).
auth: Got 'Negotiate' challenge.
auth: Got 'Basic' challenge.
auth: Trying Negotiate challenge...
2009-07-16 20:49:37.593 svn[6357:10b] *** NSInvocation: warning: object 0x1005dc040 of class 'ReplicaFile' does not implement methodSignatureForSelector: -- trouble ahead
2009-07-16 20:49:37.594 svn[6357:10b] *** NSInvocation: warning: object 0x1005dc040 of class 'ReplicaFile' does not implement doesNotRecognizeSelector: -- abort
[1]    6357 trace trap  svn -vv ls http://svn.example.com/svn/anthill/

Googling it showed one other guy who had it and never had an answer to his question.

Persistence is the codeword of the day, so I finally figured it out. Seems that OS X does things a little wonky with kerberos. A tutorial I read about using mod_auth_kerb indicated you had to use the hostname of the server, regardless of any virtualhost names (so my server name is hades, the virtualhost alias is svn; the made-up domain is, originally, example.com). Safari kept popping up the authentication dialog whenever I tried accessing the repository, which is not at all what I wanted. I had to ktadd a new principle (HTTP/svn.example.com) with the virtualhost alias (which the tutorial said _not_ to do). Then Safari started working, but svn bombed.

Of course, in Fedora 11, none of this was a problem. But here’s the weird part: klist on F11 showed HTTP/hades.example.com (from subversion or firefox), whereas on OS X subversion crapped out and crashed and Safari showed HTTP/svn.example.com. So I decided to see what firefox on OS X would do and it (properly) used HTTP/hades.example.com.

Now, the weirdest part is that svn is working again! Why? For some reason (and I’m not quite sure whether I should be blaming OS X here or neon or a combination of the two), svn is not initiating obtaining a ticket for HTTP/hades.example.com. I’m not sure why, because on F11 it did. If I kdestroy and kinit (so I only have krbtgt’s ticket), svn craps out. However, once I used Firefox to obtain the ticket, svn could re-use it and all worked well. If I remove the HTTP/svn.example.com principle on the server, svn still doesn’t work and neither does Safari (I get the login dialog). Obviously that’s not my problem. I’m wondering if these Collab binaries built for OS X are messed up somehow; I’ll have to try from fink or build from source.

This was like pulling teeth tonight. Definitely an interesting puzzle that I probably could have done without. It’ll be interesting to see if other svn builds on OS X do the same thing (of course, I could dispense with making svn use GSSAPI for this, but half the fun is seeing how many passwords I _don’t_ need). At this point I have no real idea why svn even worked at all in the first place — unless during the course of testing with Firefox I already had HTTP/hades.example.com’s ticket. Hmmm….

_arguments:comparguments:303: invalid argument: ARG

Looks like the reason is that the subversion developers changed “arg” to “ARG”. So when I googled I found this helpful post:

ZSH Tab Completion Fix for Subversion 1.5 which basically points to this new _subversion functions file to be plopped into the zsh functions directory (/usr/share/zsh/4.3.4/functions; change the version to suit of course — the directory may also be slightly different on Linux vs OS X).

Now tab completion works properly and life is good. =)

Not only that, however, but subversion will upgrade parts of your working copy piecemeal. For instance, I keep all my web development stuff in ~/svn/websites/. So after upgrading to 1.5.2 today I did some work in ~/svn/websites/intranet/ and that directory, and it’s subdirectories, were upgraded to the new format. The top-level directory, however, and the rest of the working copy, were not (they were still using format 8 rather than format 9).

I guess with a CLI client this might not matter so much, but it caused me some grief using Cornerstone, a commercial svn client. Fortunately, the author is super-responsive and pointed me to this change-svn-wc-format.py script which I can use to update all my working copies (I’m not trusting subversion to do it properly for me right now).

Anyways, if anyone else gets in this same boat, here’s some info on how to resolve it. I like using Cornerstone on my mac (it’s about the only GUI svn client I can stand); otherwise I’d be using the CLI client and probably never would have found this.