Removing “zombie-locks” from your SVN repository

Today I came across a persistent problem while trying to reintegrate a feature branch into the trunk of one of our software projects.

The problem presented itself as an error message while trying to commit the trunk which had the branch merged into it. The error message read:

svn: Cannot verify lock on path ‘/some_file_name’; no matching lock-token available

This is quite an ordinary error message which basically says that SVN has failed to lock a file (most likely due to the fact that the file is locked somewhere else).

After fumbling around a little bit, locking all the files in trunk, trying again after getting a fresh working copy of the trunk – I was still stuck with the same error.

I sat back and after reading the error message again I noticed something strange: the file which was mentioned did actually not exist in the HEAD of our trunk anymore! It had been deleted back in last September.

Now, that’s something curious – how can my check-in fail because of a non-existent file being locked?

After googling around a bit I came across the solution: it’s a bug not a feature! ;-)

This discussion sums it pretty much up while also pointing us to the solution: a python script to remove the zombie locks from the repository.

Now, when you’re running SVN on a Windows OS like we do you’re in for a bit of a ride. I tried to install Python 2.7.1 and the SVN python bindings to make the script run but I just couldn’t. I ended up copying the repository to a USB thumb-drive and running the script on the repository back at home where I have a Ubuntu linux PC.

I would recommend you to do the same, it’s a lot easier than trying to make it work on Windows Server.

Installing Subversion and the python bindings is very easy in Ubuntu linux:

sudo apt-get install subversion python-subversion

Now that you’ve installed Subversion and the bindings it’s easy as pie to get rid of those nasty “zombie-locks”:

python remove-zombie-locks.py /path/to/your/repository all

Instead of specifying “all” on the command line you may also use the revision number up to which you’d like to remove “zombie-locks”.

That’s it, you’re done and the “zombie-locks” are gone!

Pay attention to these points and you should be fine:

  • You need to stop your SVN server before performing any operations on your repository.
  • Make sure your linux computer runs the same major SVN version as your Windows Server, e.g. 1.6.x
  • If the script returns with an exception quoting a “FS Error” you’re most likely to have a version mismatch, see above
  • Make sure you’ve got a backup copy handy, just in case.

Scoped regions and navigation in Prism 4

I’ve recently started working with the Prism framework for building composite WPF applications and I have to say I’m quite impressed with what Microsoft has done there.

Prism has made it very easy for us to partition our large-scale application into reusable modules which are very self-reliant and still integrate tightly into the whole of the application – both in the business logic and the GUI layers.

Since the application we’re working on is quite complex and will offer a wealth of functionality which will be continuously added over time we need our approach to designing the application architecture to reflect these requirements.

When reading about the navigation capabilities of the Prism framework I thought that we would definitely need to implement something similar in our application.  I was quite glad to find that Microsoft had already created something so sophisticated which we could use.

The “Developer’s Guide to Prism” offers a chapter on navigation and there is a blog post written by Karl Shifflett which provides a deeper insight into navigation in the Prism 4 framework.

Unfortunately I discovered that the Prism Navigation framework does not support locally scoped regions.

What does that mean?

(If “region” doesn’t mean anything to you, it’s time to read Chapter 7: Composing the User Interface of the developer’s guide.)

Well, when using Prism’s RegionManager you have to make sure that there are no regions which bear the same name.

Now, if you create a View which has its own regions defined and you instantiate more than one instance of this View you will end up with more than one region with the same name.

Prism allows for this scenario by creating a local RegionManager when adding the View which contains regions to a (global) region.

Unfortunately the Prism Navigation framework does not yet support scoped regions.

I found a recent discussion on the Prism forum on Codeplex where someone recommended adapting the source code of Prism’s RegionNavigationContentLoader to the scenario of using scoped regions.

I have tried to do that but have failed so far to achieve a successful modification of Prism’s source.

Did anyone come across the same problem and have you found a solution? I’d love to hear any thoughts on the topic.

A StyleCop plugin for the Bamboo CI server

I’ve been using Atlassians’ Bamboo CI server for quite a while now. While it integrates tightly into all the other great Atlassian products like JIRA, Confluence or Fisheye – I have (had) some grief with it after switching from Hudson:

Bamboo is first and foremost a CI server for Java based projects. While it has been sporting support to build C# / .NET based projects for a while now, it has a lot less plugins for this platform.

Where I work we were avid fans of the Violations plugin for Hudson. It looks for data generated by static code analyzers such as PMD or Checkstyle, parses the files generated by these plugins and provides this information in a nice way on the build server’s website. The Violations plugin also supports C#/.NET tools such as StyleCop and FxCop.

Since switching to Bamboo me and my colleagues found it more difficult to keep up our software quality standards which means no StyleCop and no FxCop errors/warnings in our production code! Luckily I could convince the team to make some time for me to develop a Bamboo plugin which parses StyleCop information.

So here it is for you to enjoy: download here

What the plugin does:

1. Look for all files defined by a search pattern, e.g. “build-reports***StyleCopViolations.xml” would find all xml files ending with StylecopViolations in all sub-directories below the “build-reports” directory.

2. Parse all found files, noting the total number of StyleCop violations

3. Add up all violations, calulate a delta to the last successful build

4. Present the information on a page in Bamboo’s web interface on a per-build basis

Throw in some color coding and you can instantly see which VS projects have how many StyleCop violations.

To achieve aforementioned result you will have to configure StyleCop to generate one XML file per VS project. I have added a target file for integrating StyleCop into your build script which does that.

You can call MsBuild from NAnt so that it uses this target file like this:

<msbuild project="${solution.file}" target="ReBuild" verbosity="Quiet">
    <property name="Configuration" value="${solution.configuration}" />
    <property name="CustomAfterMicrosoftCommonTargets" value="${path::combine(project.base.dir, global.stylecop.target)}"/>
    <property name="StyleCopEnabled" value="true" />
</msbuild>

For more information please refer to the wiki page of the StyleCop plugin on BitBucket.org.

 

A great read for everyone involved with creating software

I just stumbled across this article on the web: The Joel Test: 12 Steps to Better Code. I can’t believe it that it is almost 10 years old already!

Having turned around the complete software development process at my current employer during the last year most of these steps came natural to me when I though about what was necessary to create an environment where people can write effective code effectively.

Now that the daily grind has settled in a bit, things look good. Not as stellar as I imagined in the very beginnings but I guess everyone has to accept compromises. Even though I’m happy with the progress we’ve made – reading the 12 steps again brings back the feeling that although things are going well that we’re not yet at the end of this process of renewal.

I’m looking forward to the day when I can answer every single question with ‘yes’.

Every person involved in creating software, no matter if programmer, software architect or software development manager should know those 12 steps.

Fast User Switching (FUS) and shared AFP network volumes

I have just recently bought a Synology DiskStation DS209 to serve as a centralized storage for backups, shared files and our music collection.

Since I and my girlfriend share using a trusty old PowerMac G5, we make use of Fast User Switching (FUS) quite a lot. It is a really neat thing – and hey, it’s UNIX anyway so why shouldn’t we have multiple users being logged in to the same computer at the same time.

Here is the clincher: If you want to use a shared AFP network volume it’s all fine and dandy as long as you don’t use FUS. Once you use FUS and User1 mounts ‘music’, it is mounted as ‘/Volumes/music’. User2 then logs in – but can’t access that mounted volume! User2 can now mount that volume again, this time it gets mounted under /Volumes/music-1.

Now this is a major f*ck-up. The reason is quite simple to see. Just take iTunes for example. You want to have a shared iTunes library with all your actual music files residing on the AFP mount? iTunes saves the path to the music files like this: /Volumes/music/albums/… . This means as long as your volume ‘music’ gets mounted under ‘music’ no problem – but if the second user decides to mount it as well it won’t work anymore!

Here’s a discussion in the official Apple support forum regarding the topic. Unfortunately no one has coughed up a working solution so far. Only a crude AppleScript is floating around but I’d like the implementation to be a bit more trustworthy.

I’ll keep you posted how this is getting along. I’m still all set for sharing files from a network drive AND using FUS.