Tag Archives: subversion

Help, The SVN Repo Server has changed its URL! Tips, Tricks and Tutorials 02 JUL 2014

It is inevitable that at some point in time the server hosting your Subversion (SVN) repo is going to change IP address or even URL. Of course when that happens, any SVN working copy check outs will instantly be rendered useless, moaning at the slightest touch of being ‘Unable to connect to a repository at URL…’. Obviously this makes sense because when you checked out your SVN repo you pointed it at a particular URL – with that URL now changed, you need to change your working copy details accordingly. Now obviously one solution is to just trash everything and do a fresh check out from the new SVN server URL, but needless to say, this is a bit overkill don’t you think? – especially with the existence of the svn relocate command!

Then Subversion ‘svn relocate’ command “rewrites” the targeted working copy’s administrative metadata to refer to the new repository location. Two usage syntax cases are catered for:

svn relocate FROM-PREFIX TO-PREFIX [PATH...]
svn relocate TO-URL [PATH] 

The first svn relocate syntax allows you to update one or more working copies by what essentially amounts to a find-and-replace within the repository root URLs recorded in those working copies. Subversion will replace the initial substring FROM-PREFIX with the string TO-PREFIX in those URLs. These initial URL substrings can be as long or as short as is necessary to differentiate between them. Obviously, to use this syntax form, you need to know both the current root URL of the repository to which the working copy is pointing, and the new URL of that repository. (You can use svn info to determine the former.)

The second syntax does not require that you know the current repository root URL with which the working copy is associated at all – only the new repository URL (TO-URL) to which it should be pointing. In this syntax form, only one working copy may be relocated at a time.

The two options in practice:

svn relocate http https
svn relocate http://svn.company.com/repos/trunk

It is important to remember that this type of relocation affects working copy metadata only. It will not change your versioned or unversioned file contents, perform any version control operations (such as commits or updates), and so on.

Bonus: Also, if you are getting a little confused as to when svn switch or svn relocate applies, the rule of thumb is as follows:


Remove SVN Entries without Destroying the Physical Files Tips, Tricks and Tutorials 17 FEB 2014

svn-logoOccasionally you realise that certain files have been unnecessarily added into your SVN repository, such as user uploaded photos and documents for example. Obviously this causes repo bloat and because these files aren’t core to the code base, they should best be removed from the SVN repository straight away.

However, because they are now available on the server, you can’t exactly destroy them in order to chuck them out.

Thankfully, the guys developing Subversion thought of this particular use case and as such, from version 1.5.0 and up, you now get the handy –keep-local switch to apply to a svn delete call.

The result of using this switch when calling the standard SVN delete command is the removal of the targeted files from the SVN whilst leaving those physical files safe and sound where they were – in other words only the repo metadata is updated in such a way to remove the reference to those files.

In practice:

svn delete --keep-local my_file

Very useful indeed.

SVN Commit Error: Repository Moved Temporarily; Please Relocate Tips, Tricks and Tutorials 17 FEB 2014

svn-logoI encountered a rather strange (and frustrating!) error today which was completely blocking me from committing any files into my SVN repo. After a lot of fiddling and tweaking (all unsuccessful) and finally just destroying the whole damn thing to start afresh, I did stumble across the cause and solution via Google, which means that obviously I now need to save it here for my own record.

The error Subversion was returning to me after every commit attempt read something along the lines of:

svn: Repository moved temporarily to 'xxxyyyzzz'; please relocate

The problem as it turns out is the fact that both the project webserver (in this case Apache) and Subversion are installed on the same server and thus share an Apache configuration (because you are probably using the dav_svn module to access your SVN repo).

Now if you are being clever with your 404 handling for your web project and maybe doing some redirects, and this errorDocument handler is specified on your default site configuration, then obviously your SVN module is affected by this as well. So for the one or two occasions where your SVN repo perhaps references a file that no longer exists in itself, your custom 404 redirect handler screws with the necessary SVN return error, thus resulting in the rather cryptic error message outlined above.

Luckily, it turns out that solving this issue is in fact very simple. All you need to do is edit your dav_svn.conf file:

sudo nano /etc/apache2/mods-enabled/dav_svn.conf

and add the default Apache 404 error document directive to it! A typical SVN configuration might then look like this:

<Location /svn> 
DAV svn 
SVNPath /var/svn-repos/svn 
AuthType Basic 
AuthName "Subversion Repository" 
AuthUserFile /etc/apache2/dav_svn.passwd 
Require valid-user 
ErrorDocument 404 default 

So yeah, I just wasted a lot of time by not finding this nugget via Google first.

Ubuntu Server: Recursively Remove .svn Folders Tips, Tricks and Tutorials 17 FEB 2014

ubuntu-10-logoSometimes SVN repositories just go bad and the best way forward as far as what you are concerned is to simply wipe them and start out fresh. Of course, while you can simply delete the SVN repo directly to remove it and then quickly recreate it with a few commands, you obviously need to tread a little more carefully around your existing SVN checkout – basically the collection of folders and files that you’re going to be using to repopulate your shiny new SVN repository with!

If you forgot to export your current checkout before deleting your SVN repo or perhaps the repository was too damaged to allow for exporting, you now sit with the situation where your checked out folders and subfolders all contain the obligatory hidden .svn directory which Subversion uses to store its required metadata in.

So in order to continue, we need a method of recursively removing these .svn hidden folders.

Luckily, by chaining the Linux find command with the suitable remove command, achieving this is pretty damn quick.

First, scope out just what files are going to be affected by the recursive delete function by first rather echoing out a list of affected folders/files:

find . -name .svn -exec echo {} \;

If you are happy with the list, continue with the actual delete:

find . -name .svn -exec rm -rf {} \;

Done. Of course, it’s best not to be messing around with SVN repositories in this fashion, but like most bad options in life, sometimes it is just completely unavoidable.

Ubuntu Server: Resolve Can’t Open ‘.svn/lock’ Permission Denied Error Tips, Tricks and Tutorials 05 DEC 2013

svn-logoIt’s rather frustrating when you are trying to execute an SVN command only to be rebuffed with the infamous “Can’t Open ‘.svn/lock’ : permission denied” error message string. Now this message is usually an indication that currently another session is running an SVN operation which is still in process, hence the locked message, but in the case that you are the only one running SVN commands on the box and this is the only terminal running all day, well then it’s understandable to be pretty annoyed.

But it turns out that there is another reason why this message might be rebuffing you – if you are currently not logged in as the user with rights to the files contained in the svn checkout, then needless to say you won’t have access to the .svn/lock file!

Obviously the resolution is to simply switch over to the correct user account and run the SVN command, but if you can’t, well then you could always just steal the rights to the checked out files, assuming you have sudo rights of course!

In practice:

# go to the path of your project

# reset ownership
# NOTE: replace apache.staff with your user and group
sudo find . -exec chown apache.staff {} \;

# reset permissions
# NOTE: replace ug+rw with your file permissions
sudo find . -exec chmod ug+rw {} \;

# Now you can run the cleanup command to repair your .svn folders
svn cleanup

Useful to know.

SVN Commit and SVN Update Failure Resolved! CodeUnit 08 JAN 2013

apache_logoI had a frustrating start on my first day back at work following my nice and relaxing vacation – all of a sudden it was reported to me that SVN commit and SVN update actions were now failing for the development team. What followed was a lot of frustrating troubleshooting, though thankfully I did eventually find the solution.

My first port of call was simply to restart the relevant SVN server as well as our office network IPCop machine. Following that, I confirmed that the SVN server was behaving correctly when being used by external resources, meaning that the problem had to be between our network and the SVN server. However, many fruitless hours of trawling through logs and packet capturing with Wireshark turned up nothing.

Then I stumbled across something interesting. By first tinkering with and then finally disabling Apache’s new-ish anti-denial of service module “mod_reqtimeout”, the SVN commit and SVN update actions were able to run again.

Now the Apache changelog describes mod_reqtimeout as: “a module which limits the time Apache waits for a client to send a complete request. This helps to mitigate against certain denial of service attacks. In case of problems with slow clients, the timeout values can be adjusted in /etc/apache2/mods-available/reqtimeout.conf , or the module can be disabled with “a2dismod reqtimeout”.

So one of two things must have happened: either apache was updated on the SVN ubuntu server, or our internal network has somehow slowed down. In any event, at least we can work again – just a pity it took 4 or so hours to get there!