Linux

Here are a couple of common SVN problems I have come across a lot recently and their resolutions:

svn: Checksum mismatch for ‘.svn/text-base/blah.ext’; expected: ‘f8d45250f7df5561635854165862fdd8?, actual: ‘644f85c4befa671150c5c6ec5fad9885?

This tends to be due to the SVN repository data getting corrupted, this tends to happen with users using SSHFS to get to their working copies.

There are 2 ways to fix this, the first is to remove the directory in question and do an SVN up, this may not always be practical because you can have uncommited changes in the working copy.  The second is to rename the affected file (.svn/text-base/blah.ext) to something else to preserve it, then edit .svn/entries.  You should find in the file a section like:

^L
blah.ext
file
 
2007-08-22T12:26:44.000000Z
f8d45250f7df5561635854165862fdd8
2007-08-21T22:28:44.968799Z
410
hans
^L
gamingzone.php

You need to delete between the two '^L's (preserving one of them).  You should then be able to do an SVN update and the file will be repaired from the repository.

The second issue is when you get this error whilst doing a merge (and probably a few other operations):

svn: REPORT of '/repos/firstpost/!svn/bc/525/trunk’: 200 OK (http://10.1.1.70/)

The fix for this issue is pretty simple, the repository was created using SVN 1.4 and the server software has been upgraded to 1.5.  When you do this the repository databases also need updating to support the new merging featues in 1.5.  To fix this simply run on the server:

svnadmin upgrade /path/to/repo

Both forward and reverse SSH tunnels have proved very useful to me lately on a project I have been working on for Dennis.

Forward SSH

Forward SSH tunnels are used to send ports via. an SSH tunnel, this is useful to get around firewall restrictions if for example a mail port is closed but an SSH port is open.  It also encrypts plain text data in the process.  For the application I was using it for I needed a computer to get WebDAV SVN data in a random remote location from a server that is firewalled out from the outside world (apart from SSH).

For this example port 6500 is open on the firewall to allow incoming SSH.  We are basically telling port 8080 on the local machine to go through the SSH tunnel and come out as port 80 remote end (VPN was not practical in the real solution).  Because we are using named based vhosts on Apache on the remote end we set the local end to use http://localhost:8080/ as a proxy in SVN, this can be done in ~/.svn/servers.  The line to connect is as follows:

ssh -q -p 6500 -N user@remote.server.com -L 8080:localhost:80

The -p parameter tells SSH the port for the remote SSH server.  The user@remote.server.com is the standard SSH login details for the remove SSH.  The 8080:localhost:80 basically states that port 8080 on the local machine should become port 80 on the remote machine.

Reverse SSH

Reverse SSH is used to create a tunnel similar to the forward SSH example, but it is used for the server to connect back to the remote machine down the tunnel instead.

In this example we want a user on the server to connect via. SSH to the remote machine, but we will never know the remote machine's IP.  So we open the tunnel from the remote machine to the server and then the user can connect.  Again we assume the firewall is open on port 6500 for SSH.  When a user is on the server and connects to port 5000 they will reach port 22 on the remote machine (this can be used for other ports and protocols easily though).

ssh -q -p 6500 -N -R 5000:localhost:22 user@remote.server.com

You can see here we are using the -p 6500 again for the SSH port, this time 5000:localhost:22 means port 5000 on the server connects to port 22 on the remote machine.

There are other ways of doing the above such as VPN and dynamic DNS providers, but I think you find this a nice alternative when those solutions are not pratical.