Their prices are fair, their site is well designed and easy to use, and they don’t try to cross sell, up sell, or otherwise try to get you to buy services you don’t want. My impression is that the folks at gandi believe technical competence combined with ethical business practices will win and keep customers. Truly a breath of fresh air.

Not so for a centralized vcs such as Subversion. If you check out a copy of a project, you have a local copy sans the history of the project. Backing up the entire history of the project takes a bit of doing. This post concerns a method for creating a live mirror of a Subversion repository.

Here is the problem we are going to solve. You have a working Subversion (svn) repository. It contains valuable code, so naturally you want to back it up, both on a local machine, and maybe an offsite machine as insurance against disaster striking your site.

You could try to back up your repository by backing up the physical media containing the files which constitute your repository, say using rsynch-backup or some such. I don’t like that approach because if you ever have to use your backup, your first step will be to try to turn a bunch of files into a working svn repository. No thanks, I’d rather have a running svn instance all set to go.

I’ll show you how to back up your svn repository using three very simple bash scripts, and later give a link to to where you can download the scripts. Here’s the first one, make-svnrepo.

#!/bin/bash
## The user should edit this script to insert appropriate repository paths.
## The goal is to mirror ${REMOTESVN}/${REPO} in ${LOCALSVN}/${REPO}, which is created here.
## The population of ${LOCALSVN}/${REPO} is done via another script, sync-svnrepo

REPO=${1}                             # name of repository passed in by user
REMOTESVN='10.0.0.11'                 # omit final "/" since script provides it later
LOCALSVN='/home/drc/repo/saffronsvn'  # ditto
LOCALREPO=${LOCALSVN}/${REPO}         # the file path to local svn repository about to be created
PROTOCOL=svn                          # the transfer protocol to be used : one of {svn,  svn+ssh, file}

## Sanity check: uncomment the svn info command below, and make sure it works.
## If it does not, you are not talking to the remote repo, and may not have correctly specified some component above.
## svn info ${PROTOCOL}://${REMOTESVN}/${REPO}

## do the magic
svnadmin create ${LOCALREPO}
echo "#!/bin/bash" > ${LOCALREPO}/hooks/pre-revprop-change
chmod +x ${LOCALREPO}/hooks/pre-revprop-change
svnsync init file://${LOCALREPO} ${PROTOCOL}://${REMOTESVN}/${REPO}

How would I use this? Well, I have an existing svn repository running on my LAN, on a host with internal ip address 10.0.0.11. Suppose it hosts a project called MyProject. I want to mirror that entire project on my local machine, in the existing directory /home/drc/repo/svn. I have already installed Subversion on my local machine, and make-svnrepo is marked executable and is in my path. What I have to do is run the following in the console:

make-svnrepo My-Project

This will create an empty project. To populate it, use the next script, sync-svnrepo:

#!/bin/bash
## You will want to run this periodically, say via a cron job. I run it 4x daily.
LOCALSVN='/home/drc/repo/saffronsvn'  # should agree with LOCALSVN in make-svnrepo
REPO=${1}
REPOSITORY=${LOCALSVN}/${REPO}
svnsync sync file://${REPOSITORY}

As you might expect, we would populate the mirror created in the first step by running the following in a console:

sync-svnrepo My-Project

This has to be done on a regular basis to keep up with changes; cron does the trick for me. I imagine it would be possible to use hooks within the original repo to trigger backups whenever code is committed, but I prefer not to touch the original repository.

What I’ve done at work is to mirror our working repository in three separate mirrors. Two are onsite, one is offsite. I use the following script, query-svnrepo, to check up on the status of the mirrors.

#!/bin/bash
NAME=${1}
echo "---> " ${NAME}

## The idea here is that we have mirrored the repo named by NAME is in several places
## We want to check that revision numbers on the mirrors more or less agree with the original repo's numbers

ORIGINAL=10.0.0.11                       ## on our lan
MIRROR1="/home/drc/repo/svn"             ## file on localhost
MIRROR2=10.0.0.66/svn                    ## on our LAN
MIRROR3="foo.bar.org/home/drc/repo/svn"  ## offsite, requires ssh access
COMMAND='svn info '

## adjust the protocol as required for each mirror
REPOSITORY=${ORIGINAL}
PROTOCOL='svn://'
RESULT=`${COMMAND} ${PROTOCOL}${REPOSITORY}/${NAME} | grep "Revision:"`
MSG="original:  ${RESULT}"
echo $MSG

REPOSITORY=${MIRROR1}
PROTOCOL='file:///'   ## the third / is needed as an escape because the path begins with /
RESULT=`${COMMAND} ${PROTOCOL}${REPOSITORY}/${NAME} | grep "Revision:"`
MSG=" mirror1:  ${RESULT}"
echo $MSG

REPOSITORY=${MIRROR2}
PROTOCOL='svn://'
RESULT=`${COMMAND} ${PROTOCOL}${REPOSITORY}/${NAME} | grep "Revision:"`
MSG=" mirror2:  ${RESULT}"
echo $MSG

REPOSITORY=${MIRROR3}
PROTOCOL='svn+ssh://'
RESULT=`${COMMAND} ${PROTOCOL}${REPOSITORY}/${NAME} | grep "Revision:"`
MSG=" mirror3:  ${RESULT}"
echo $MSG

This system has worked like a champ for me. I have never had to use the backups, but it’s nice to know they are there. And it is real nice to know that they work. This can easily be tested by checking out the project from one or all of the mirrors.

Screen scraping code can be a pain because blogging software sometimes does weird things to certain characters. You can get clean copies of the scripts from my repository on BitBucket.

If you actually use any of these scripts, let me know how it goes. I’d be happy to hear any suggested improvements.

I brought the device back to my ubuntu box, plugged it in, and nothing. The drive did not auto-mount, there was no sign of it in /media, and I could not see any new device using “sudo fdisk -l”. At that point things did not look entirely promising. It’s hard to use recovery tools on a device if you cannot see it.

And then I got lucky.

The drive was powered up, spinning away, and I was holding it in my hand, thinking about what to try next. I don’t know the rotational speed of the drive, but it must be pretty high. I could feel the gyroscopic precession effect resisting changes to the drive’s axis of rotation when I moved my hand. It is an interesting, almost eerie sensation. I played with drive, feeling the effect, for about 10, maybe 15 seconds. As I did so I heard a clicking sound, and suddenly the drive auto-mounted and a Nautilus window came up showing the contents of the drive. I quickly dumped the 14GB of data to another drive.

It’s good to be lucky.

I make a habit of leaving the to: field empty until the body of the email is completed. That way if I hit send by mistake, the client has no one to send to. This has proved useful several times.

First I downloaded the source for the recently released python 2.6, along with the source for the current versions of tcl and tk. I put all three in /home/drc/local/:

cd /home/drc/local
wget http://www.python.org/ftp/python/2.6/Python-2.6.tgz
wget http://prdownloads.sourceforge.net/tcl/tcl8.5.4-src.tar.gz
wget http://prdownloads.sourceforge.net/tcl/tk8.5.4-src.tar.gz

I then unpacked all three downloads, and built them in this order. First tcl:

cd /home/drc/local/tcl8.5.4/unix
./configure; make; sudo make install

To get the nice fonts with tk requires a little preparation.

sudo aptitude install libxft-dev

Now we can build tk.

cd /home/drc/local/tk8.5.4/unix
./configure --enable-xft; make; sudo make install

Next we build python 2.6. We can take care of getting the dependencies set up by picking up the dependencies for python 2.5.

sudo apt-get build-dep python2.5

Finally we are ready to compile python 2.6. I kept it local so not to mess up Ubuntu Hardy, which relies on python 2.5.

cd /home/drc/local/Python-2.6
./configure --prefix=/home/drc/local/python2.6
make; make install

Everything is built. All we need now is a simple bash script to launch Leo. Here’s what I use:

#!/bin/bash
LOCAL=/home/drc/local
PYTHON=${LOCAL}/python2.6/bin/python
LEO=${LOCAL}/Leo-4-5-1-final/
${PYTHON} ${LEO}/launchLeo.py ${1}

If you happen to find this useful, or have any corrections, suggestions, or comments, I’d love to hear from you. Leo is a wonderful and very useful program. I am delighted to finally have a nice looking version running on linux.

Here’s the obligatory screen shot.

apt-get build-dep <package_name>

This will get all the dependencies needed to compile your package - providing that package_name is something that would normally install using a simple apt-get install command.

For example:
If you wanted to download and install the latest version of gnucash from tar.gz. You would run:

apt-get build-dep gnucash

process_info(Pid)

i()

erlang:processes(), or better yet, rp(erlang:processes()). Sometimes long lists show “…” to represent the tail elements. Wrapping in rp() shows the whole list.

Finally, exit(Pid, kill) to kill the process represented by Pid. For a while I thought that exit(Pid) sufficed, but some experimentation using the commands above will show otherwise.

The sad truth is that Leo does run on linux, but it uses tcl/tk for its gui. With the versions of python and tcl/tk currently available on Ubuntu Hardy, Leo’s font rendering is so bad I can’t bear to use it. Leo looks great on Windows, bad on linux, and perhaps even worse on Mac. Strange.

I spent some time trying to track down a way to get antialiased fonts working for Leo on Ubuntu, but had no luck. I did find a thread that suggested installing tcl8.5 and compiling Python from source, but decided not to bother with it. Intrepid Ibex is supposed to be released end of next month, and Python 2.6 is also due for release in October. I can wait a bit longer. Another few months and I think there is a decent chance that Leo will provide antialiased fonts out of the box.