December 2005


For anyone who has not heard of Subversion , it is an open-source version control system (very much like CVS but much better) to manage your source code. I had started to play with Ruby on Rails using the RailsIDE and I would hate for my source code to be without version control and much worse just kept in my hard drive. So I wanted to have a version control for my personal projects just like I do at work. And I didn’t want to host this subversion repository in my windows box at home, I would rather keep it at the ISP machine where I host my domain. Sounds simple enough, right?. Wrong!!. I found so little on the net about it that I was compelled to write this down for others who might want to do this . Here is a step-by-step guide on running and connecting to a subversion repository in an ISP account.

Before we get started, there are a few assumptions:

  • Your ISP provides you with shell access using ssh. You can’t do what I am describing below using Control Panel. Not all of ISPs allow Shell access and some will do it if you ask them. This is an absolute requirement.
  • You have permission to install anything under your user directory. This I know almost all of them allow you to do.
  • Step 1: Installing subversion server

    The following instructions are for a linux machine. Surf to subversion site and look for the latest stable source code package. When I did the install , this is what I ended up using: http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.gz. Now ssh into your account and do the following:


    $ cd $HOME;
    $ curl -o subversion-1.1.4.tar.gz http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.gz
    $ gunzip subversion-1.1.4.tar.gz; tar xvf subversion-1.1.4.tar
    $ mv subversion-1.1.4 subversion-1.1.4-dist
    $ cd subversion-1.1.4-dist
    $ ./configure --prefix=$HOME/subversion-1.1.4
    $ make
    $ make install
    $ cd $HOME; ln -sf subversion-1.1.4 subversion

    Thats it. Add $HOME/subversion/bin to your PATH variable and you are all set. Now its time to create a svn repository. I chose to use $HOME/svn as my svn repository.

    Now test your subversion install by adding a dummy project to the subversion respository:


    cd $HOME;
    mkdir projects;
    cd projects;

    # create a dummy project source
    mkdir -p dummy-project/src
    touch dummy-project/README

    # add the project to subversion
    svn import -m "Initial Version" dummy-project file://$HOME/svn/dummy-project

    If everything went according to plan, your project is now in subversion.

    There is not much use to a subversion server if it can only be accessed locally. There are three ways to front a subversion server to access the repository remotely: using apache webserver (using http://) , using a custom svnserve daemon (using svn:// url scheme) or by tunnelling svn over ssh (svn+ssh://). The first two options are automatically out for a hosted account and the only option is going svn over ssh.

    Step 2: Connecting to subversion by tunnelling over ssh (svn+ssh)

    This is where I found the least documentation and most difficulty. To connect to the subversion repository you two pieces of software on your client machine : a subversion client (I use tortoise svn) and a ssh client (I recommend Putty) . Install putty and the utilities it comes with preferebly through a windows installer (http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.58-installer.exe). Install Tortoise subversion to c:\TortoiseSVN (The default location in Program Files will create a problem later during ssh configuration).

    In order to tunnel svn commands over ssh , you need to be able to ssh to your ISP account without having to give a userid and password every single time the client wants to talk to the server. There is a way to setup a public-private key pair to enable this dialogue without a need for entering a userid and password.


    $ ssh-keygen -t dsa -f mykey

    You will see two files mykey and mykey.pub, the openssh private and public keys. Now add the contents of mykey.pub to the file $HOME/.ssh/authorized_keys in your shell account. Create the directory and file if you don’t have it already.

    Now add the following to the begining of the line you just added to the authorized_keys file. It should look something like this (replace your-home-dir with the right value):

    command=”your -home-dir/subversion/bin/svnserve -t -r your -home-dir/svn” ssh-dss AAAA……………

    Now move the private key file mykey to the windows machine that you will be connecting to subversion from. Run puttygen.exe, and click the button Load and choose the mykey that you just moved from your shell account . Putty will successfully load it and now you choose the “Save private key” button and save the private key in putty format as mykey.ppl. Save this to c:\TortoiseSVN\bin.

    Now run Putty.exe and under Session choose ssh , your host name , in Connection->Data enter your login name, Connection->SSH->Auth section , click the Browse button to choose the private key file. Now choose c:\TortoiseSVN\bin\mykey.ppk. In Session, give it a name like SVNConnection and choose Save. Click the open and you should see the following :

    Using username “your-user-name”.
    Authenticating with public key “imported-openssh-key”
    ( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )

    This means your ssh connection to subversion is working. Now you just need to get the subversion client (tortoise svn) to use the private key file when connecting to your repository. In the following subversion config file (C:\Documents and Settings\Your-User-Name\Application Data\Subversion\config) look for the section title tunnels:


    [tunnels]
    ### Configure svn protocol tunnel schemes here. By default, only
    ### the 'ssh' scheme is defined. You can define other schemes to
    ### be used with 'svn+scheme://hostname/path' URLs. A scheme
    ### definition is simply a command, optionally prefixed by an
    ### environment variable name which can override the command if it
    ### is defined. The command (or environment variable) may contain
    ### arguments, using standard shell quoting for arguments with
    ### spaces. The command will be invoked as:
    ### svnserve -t
    ### (If the URL includes a username, then the hostname will be
    ### passed to the tunnel agent as @.) If the
    ### built-in ssh scheme were not predefined, it could be defined
    ### as:
    # ssh = $SVN_SSH ssh
    ssh = C:/TortoiseSVN/bin/TortoisePlink.exe -2 -i C:/TortoiseSVN/bin/mykey.ppk

    Now open the Repo-Browser of TortoiseSVN and enter the URL to your dummy project:

    svn+ssh://SVNConnection/dummy-project

    and you should see the files under dummy-project. If you can’t connect, its probably because you didn’t setup the puTTY session correctly. Verify that you entered all the required information correctly.

    You can connect to svn repository from inside RADRails using the following URL (this does not work in TortoiseSVN for some reason):

    svn+ssh://your-user-name@your-machine-name/dummy-project

    Whoa. I haven’t blogged in a long while now. But since I was off on vacation for a month in November, I have a good excuse. I have some Google desktop hacks to share. Actually I have a hack to share. But its a useful one. I have been using Google desktop for a while now and I have a lot of emails (in archives of course) and files that it indexes. The cache has been eating away so much of my C: space where I can’t do any decent work anymore. So I went registry hunting for a way to move the cache from my c: drive to my external drive (a huge 160 gb). And I actually found a way. Here is how (This is not for the faint of heart. Doing wrong things to your registry might render your machine useless. Consider yourself warned):

    shutdown google desktop by right clicking on the tray icon and choosing exit.
    start->run and type regedit
    In regedit go to My Computer->HKEY_CURRENT_USER->Software->Google->Google Desktop
    On the right you will see an entry data_dir. Double click it and change the value data to a directory of your choice.
    now start google desktop again and you should see your cache in that directory.

    Some words of caution though:

  • Don’t make your cache go to a network directory. You will completely flood the network. Google writes a lot to the cache.
  • If you choose an external drive as your cache, turn encryption of index and datafiles on in Google desktop preferences. This might take google desktop longer to index, but it is the wise thing to do because anyone could take off with your external drive more easily than your desktop.
  • In my case I reinstalled the google desktop (because I was upgrading to a new version) and removed all the indices and cache and then changed the data_dir fresh after an install. I am not sure if it works as expected if you just changed the registry entry without a reinstall.