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.

This is why Intel bought the Havok physics engine. AMD kills the GPU physics implementation. Makes total sense from Intel's point of view, last thing they want is for more processing to be moved off of their widget. This will probably also effect the PhysiX Accelerator card as well. Now the only hope for accelerated physics on the GPU is going to be Microsoft's APIs for physics acceleration.

Personally I think that this sucks. I mean I didn't have much hope for physics acceleration as being the next great thing with regard to video simulations but I do think that killing a project just because they don't have a good competing product is a bad thing. Both Nvidia and AMD/ATI are trying to increase the amount of usable computer power while Intel is just trying to maintain their competitive advantage.

I want to see more and more processing moved to a GPU or other external CPU when it makes sense, but developers will not do so unless there are libraries that abstract this complexity out for them. Software should be able to dynamically respond to the hardware it is being run on to achieve maximum performance when desired. That's why DirectX has been so successful, cause even when things are not supported natively, many computers can still use software emulation to achieve the same effect (at reduced performance sometimes).

Basically I want the ability to easily throw more hardware at a problem and have it work.

What Sun needs to do with Java (as a platform).

• Stop including every little pet feature as part of the standard platform. Create a better extension mechanism and use that instead.
  
• Make the initial download smaller.
• Make it trivial for users of the JRE to get dependencies in software.
• Start a network library repository that stores different versions of java libraries for download by jre clients. It should be trivial for end users to get any software in this repository so that any sanctioned software.
  
• Embrace SWT and other competing technologies. They should stop hampering other technologies just because they prefer their internal technologies.
• Make the VM a place where any code from any language can run, which is a move twords the CLR of the .NET platform but a good one. The JVM is a good place to run lots of code and by being language agnostic the platform is only enhanced.