Adventures in SVN

It's been blogged about before and will probably be blogged about again, but getting svn installed as a launchd service in OS X is both easy and fustrating at the same time. It seems like it should be like a checkbox somewhere cause at the end of the day it's not that hard. My task was simple, just install svn so that I don't have to keep on restarting it every time my cat hits my power button or other power related failure happens to my server computer. Which now happens to be an iMac G5 running Leopard. Also is the added trick of making sure that my windows laptop can easily checkout the repository.

I started with a simple google search which led me to some old pages.

"Starting svn with launchd" which led me to Mr. Paulus' page on doing the exact same thing with his Mac Mini in Tiger. Problem was that both these pages don't actually solve the problem anymore because of changes of svn. Fortunately Mr. Paulus' page linked to yet another blog where he got the instructions on how to use launchd in the first place. Marc Pacheco's page has been updated.

My problem was that I got the service installed but nothing could talk to it. This was because I guess svn now likes to use IPv6 instead of IPv4. The original launchd plist has instructions to use IPv4 which causes the problem.

Ok, no prob, just change to IPv6, or do what I did and just remove the specification completely. This fixed the issue for me at least, on my Mac.

Windows on the other hand doesn't like to install IPv6 by default in Windows XP. So in order to get this working at all I had to install IPv6 for my network adapter on my Windows XP box. I have also found out that at least in my experience, installing IPv6 on windows also improves the speed of any file sharing that you are doing between the 2 platforms. I don't know if this is just something that happened to me or if it's proven elsewhere, but it helps a lot.


Here's my final file that 'works for me' in Leopard. If you use it make sure to replace the --root=... with your repository location.

<plist version=\"1.0\">
<dict>
 <key>Debug</key>
 <false>
 <key>Disabled</key>
 <false>
 <key>Label</key>
 <string>svn</string>
 <key>OnDemand</key>
 <true>
 <key>Program</key>
 <string>/usr/local/bin/svnserve</string>
 <key>ProgramArguments</key>
 <array>
     <string>svnserve</string>
     <string>--inetd</string>
     <string>--root=svnrepository</string>
 </array>
 <key>ServiceDescription</key>
 <string>SVN Code Version Management</string>
 <key>Sockets</key>
 <dict>
     <key>Listeners</key>
     <dict>
         <key>SockServiceName</key>
         <string>svn</string>
         <key>SockType</key>
         <string>stream</string>
     </dict>
 </dict>
 <key>Umask</key>
 <integer>2</integer>
 <key>inetdCompatibility</key>
 <dict>
     <key>Wait</key>
     <false>
 </false>
</dict>
</true>
</false></false></dict>
</plist>

This isn't new, but if you are a programmer and haven't read this then you must spend the time to read and fully understand this
PDF
written by Ulrich Drepper from Redhat.
It's an amazingly good summary of almost all too much information about memory and CPU systems and how they interact to make every program run much slower then it needs to be. It goes into the detail of how RAM is actually constructed and goes through all the memory systems in use by common hardware today. With tests and benchmarks to backup all his claims and to show the dramatic difference that good code can make.

The only problem I had with his paper, and maybe this isn't a problem with the paper as much as an issue with programming in general is that it doesn't cover non-hardware level optimizations that people can do. Most of the optimizations that one can do at the level of memory are just not possible in most 3G+ languages (Java, C#, Python, Perl, ECMAScript, ActionScript, etc.). Some are, like minimizing the memory footprint of your data structures. But how else are all those non-c/asm/c++ level programmers supposed to increase their utilization of memory.

It's the curse of being abstracted so far away from the hardware. No way to optimize at this level. It's not like Java can prefetch memory into a the vector units or stream directly to/from main memory without using the cache. I guess you could but then you'd be calling into a c program which is outside the normal bounds of a Java program since technically you're no longer in Java.

Not that I'm saying that programmers need a way to do every single trick in the book from all languages, but having no control over your memory is almost as big of a curse as having to control the layout of every byte.