Subversion is my favourite version control system. I’ve been using it for about two years now (I first wrote about it first in april ’07) and so far I am very happy with it. It was built as a replacement for CVS, which was the standard version control system in the Unix/Linux world and more or less de facto standard for opensource projects at the time when Subversion was started (sometime in 2000). Subversion took the best ideas from CVS, added some very interesting concepts and solved most of the problems that people had with CVS (but not all of them). It is now the typical choice for any new Java projects and replaced CVS as the standard version control system in most of the opensource projects. Over the last few years, it is becoming more and more popular for Windows .NET projects as well.

Lots of tools for Subversion

CVS was never really popular among developers working on Microsoft Windows because of poor tool support. SVN, on the other hand, has very good support for Windows. In fact, good tool support is one of the best things about Subversion. Since it is used on so many operating systems and for so many development platforms, Subversion has quite a few tools that you can use. The default one that comes with the basic installation is the command line tool, which gives you full control of the system but it is not really what is normally considered user friendly. Even if you are not used to command line tools, I suggest looking into it because it will help you automate tasks. A very interesting Windows tool is TortoiseSVN, an opensource plugin for Windows explorer that allows you to perform all operations with Subversion from the normal Windows file window using a right-click context menu. TortoiseSVN is a great tool for people that do not want to use an IDE or learn another tool, such as business analysts that just want to check-in and check-out acceptance tests. It is also useful for database developers that use IDEs such as TOAD which have no concept of version control.

Two another very important tools for .NET developers are AnkhSVN and VisualSVN. AnkhSVN is an opensource plugin for Visual Studio which enables you to perform version control operations from the IDE. I use the command line SVN tool for everything, so I’m not really the best person to tell you about ins and outs of AnkhSVN. I evaluated it the last time more than a year ago, and it was not really functionally complete but it could do the basic operations. Apparently it has been significantly improved over the last few months. If AnkhSVN does not do the job for you, try VisualSVN, a commercial Visual Studio plugin that integrates SVN as a source code control system into Visual Studio. It’s not very expensive, and should have all the functions that you might need. Again, this is just from what I’ve heard, I do not use it myself.

A tool that is especially interesting for me is ViewVC. ViewVC is a web front-end to Subversion, running on Apache. It will give you proper read-only access to a SVN repository using a browser, so it is very useful to look at the changes or code from a machine that does not have SVN installed. In the past, I used this to give the support team access to the code and deployment history. Subversion itself can provide HTTP access using Apache, without additional tools, but you need to remember a lot of cryptic URL commands for that. ViewVC gives you a point-and-click interface to browse revision history, see colour-coded differences between versions and browse through the repository. For a live demo, see the dbfit project repository on Sourceforge.

In general, you’ll find that opensource tools have great support for Subversion. Cruise Control .NET, for example, supports Subversion out of the box even for initial checkout and labeling. Team System support is still incomplete. So if you want to use lot of .NET opensource tools in your process, putting the code on Subversion makes a lot of sense.

Subversion is atomic

The best feature of Subversion is atomic commit. That means that the whole change set is either going to succeed completely or fail, regardless of how many files there are in that set. For example, if you did a big refactoring of the source code and want to commit 50 files, but the 47th commit fails because someone else modified that file meanwhile, changes to the first 46 files will be rolled back on the server and you’ll be asked to resolve the problem before committing again. If the commit went through partially, the build would fail on the server and you would have to check what was committed and what failed. So the atomic commit solves a lot of consistency issues that happen with some other version control systems.

There are two more important things to know about those atomic versions. First is that the whole repository has a unique version sequence, incremented on every commit. Second is that Subversion stores only differences between versions for text files in the change log. These two features have some interesting implications. For start, you don’t have to remember to tag important versions. Version completed by each commit is assigned a unique number, and you can easily use that number to download the snapshot of how files looked like at that point in time. On .NET projects, I use this as the DLL version. When you need to troubleshoot, right-click on the DLL, see the version number and then you can easily checkout the exact source of that code version. Another important thing coming out from storing only the differences in files is that tagging and branching effectively does very little — it just creates a new revision without modifying any files. So you can easily tag or branch 50 MB of files in a millisecond.

Subversion works smart

Subversion has many smart functions that make it a very good choice for a development version control system. It really helps to automate some of dull tasks.

Storing differences in text files and automatic versions allow Subversion to provide one very interesting auditing function. Called “blame”, this function lists a file with every line marked with the last change version and the person who changed it. (This is available on the web frontend viewvc as well — see a live demo again on Sourceforge).

Since versions are stored as differences, we can easily roll back any particular version by reversing the differences, without affecting any other changes. Similar to that, we can take a particular set of differences (eg changes to a branch) and then apply it to different files (eg main branch). So Subversion makes merging branches relatively easy.

Subversion is also smart enough to understand that it is rarely the only tool applied to a project, so it does not require you to check-out large branches in order for tools that don’t know about Subversion to work correctly. It will find new or missing files and folders and appropriately suggest adding or removing those from the repository. Subversion works in edit-and-merge mode which means that two people can work on the same file at the same time, as long as they do not change the same line, and it will be able to merge the changes correctly.

The only real problem with Subversion, also inherited from CVS, is that it is a folder-based system, which means that it will store meta-data in a hidden .svn folder inside your folders. If you rename or copy a folder that was committed to the version control, you will also copy the meta-data files but they are no longer correct. So changing something and committing back will actually change the old location on the version control server. Renaming and moving individual files is not a problem, but with folders it is much more complicated. That’s where TortoiseSVN can help again, since you get the subversion rename, copy and move functions basically in the same menu as the normal ones, so you just have to remember to click on the correct option.

Links for the end

Here are some links to download tools or look for more information:

• Main subversion site
• AnkhSVN
• TortoiseSVN
• VisualSVN
• ViewVC

Image credits: Locomoco, Derek Farr, Pierre J.

NHibernate – Ian Cooper
PowerShell – Zi Makki
OpenRasta – Sebastian Lambla
Castle Windsor – Mike Hadlow
Rhino Mocks – Chris Roff
NServiceBus – David De Florinier
Subversion – Gojko Adzic

The event is free but the number of places is limited. Apparently about half of the places are already taken and Skills Matter have not yet started to advertise it seriously, so if you were planning to come to the event make sure to register soon. For more info and to register click here.

See you on 31st.

I read a lot about Subversion, but never really had a reason to move from CVS – there was no new killer feature. We were generally satisfied with CVS, with just one problem. Integration with Visual Studio was virtually non existent. In January, several readers suggested trying out Subversion instead of CVS, and shortly after I took their advice. It turns out that the killer application, that made us move to Subversion, was the Visual Studio Plugin.

Migration from CVS

The migration from CVS was relatively easy. Subversion does edit-and-merge like CVS, works good over WAN lines, has proper GUI client tools for Windows and a command-line interface for easy scripting.

In terms of usage, two biggest differences from CVS for me were attributes and the branching system. In CVS, files are ignored just by adding their name to .cvsignore. Subversion does that with directory properties (use propset option from the command line). We migrated the repository quickly with a small shell-script that ran through the repository tree and loaded .cvsingnore into directory properties.

Branches and tags are just copies in Subversion. This makes branching somewhat simpler, as just a part of the repository can be copied (and branched), without affecting the rest. However, at first I had big reservations regarding tags as copies. With CVS, I used tags to mark a release or a significant starting point before a big change, so that I could easily go back. I thought that copying would just take too long and that it would take too much space. However, it turns out that copying in Subversion is not physical – a new branch or tag is created with a simple atomic operation that just sets up a link from the new location to the current version (from that point, of course, the copy can be modified independently).

Subversion also has automatic versioning of the complete repository, not just per file. Each commit operation is assigned a unique version number – this pretty much takes care of marking important savepoints, as we can go back and take the whole repository in a specific version. Although we could theoretically use these numbers to track releases, I still like to tag released files and give them a sensible descriptive name, instead of remembering that last iteration was 1182.

From the user perspective

Subversion has quite a few features not present in CVS. Most importantly, SVN does atomic commits (so the entire batch of related updates will fail or succeed), and can work natively over HTTP, so you instantly get a web-based interface just for browsing. Automatic versioning allows the system to keep track of which line was changed by whom in which revision, and that information is easily accessible as the ‘blame’ feature (maybe not the best name, but it makes a point). File renaming and moving are also versioned, so Subversion does not get in the way of refactoring.

In terms of client software, the Eclipse plugin for SVN looks and behaves very much like the CVS plugin (with a few added functions), but I did not see any major differences between them.

On Windows, we are using TortoiseSVN, a free plugin which provides access to the repository from the windows file explorer. It works very similar to TortoiseCVS, but has a few added functions for differences and merging.

AnhkSvn turned out to be a very interesting tool, providing direct integration with SVN from visual studio. In terms of features and performance, Tortoise seems better, so we tend to use both. AnhkSVN is good for files being developed in Visual studio, as it automatically adds new source files to the repository and gives us quick visual feedback of what was changed in the whole project tree. The only “problem�? I have run into is when it stops renaming files which were added but not yet committed. I occasionally change my mind about the class name (and file name) soon after a new file is created, and file renaming just silently dies when AnkhSVN is turned on. This was a bit frustrating at first, but once I realised what the problem is, it was not hard to work around it. All in all, very useful.

An important feature for us was also the integration with Cruise
Control.Net. Since version 1.2, CC.Net can automatically check out source folders from SVN (even the initial checkout, which is not available for CVS), and can tag successful builds.

From the admin perspective

SVN repository setup is straight-forward, like CVS, but there are quite a few options how to set up the whole system, so analyse them carefully if you are thinking about moving to subversion.

SVN does not have modules, like CVS, but allows the users to check out individual directories. Tags and branches complicate things a bit, because they are also accessed directly from the main file structure (they are just copies of files). With all this flexibility, it’s important to structure the repository so that people can check-out only relevant parts. This typically means that the top-repository level should be divided straight away into branches, releases, automated builds and the current working copy (called trunk in SVN language). We missed that one – and decided to structure the repository first by sub-projects and then do a division between source, branches and tags on the second level. It turned out that this made it hard to check out all related projects quickly. The next time we shake-up the repository, the first level will probably provide a division between trunk and copies, and projects will be on the second level.

SVN has two options for repository storage – individual files (similar to CVS) or an embedded database. Apparently, the first is a bit slower for access, but supports online backups and can be repaired easier in case of problems. We chose to use files, and (luckily) so far did not need to test the proposition that files can survive crasher easier. As for performance, it was quite good with files, so I don’t think that we will be moving to the database any time soon.

There are also several options for remote access. SVN has a binary protocol (which can work over SSH) and there is an Apache plugin which provides HTTP(S) support. Our version control server runs on Linux, and we decided to use Apache for several reasons:

• easier disk privilege management – entire repository is owned by a single user on server, access controls are handled by Apache
• new users can be added easier – they do not have to be system users, but are just defined in a httpd users file
• access control lists can be specified for a part of the hierarchy, and all ACL lists are in a single file, easy to control
• HTTP server automatically allows repository browsing
• Theoretically, having multiple users access the repository through a single funnel (in this case HTTP server) will reduce the chance of file corruption.

There are a few other advantages of working over HTTP like support for online GZip traffic compression. Again, the performance was quite satisfactory, both on the local network and on WAN lines. It would probably run faster with a binary protocol, but isolating under an Apache module makes the repository much easier to manage.

Although Apache module itself provides support for repository browsing, we also installed viewvc, a better Web-based interface which displays last modifications and provides basic support for checking differences online.

The story so far

So far, I am happy with Subversion and what it has done for us. The only real problem we encountered in these three months is bailing out after something was committed by mistake. With CVS, repairing the problem would be simply checking out a tagged revision, then committing over the repository again. SVN makes this quite hard because it remembers the revision you checked out, so it’s not easy to override the current version with an older one. So far, we had to deal with this situation three or four times, by copying the old revision to an external location, checking out the latest version, then copying files from the external location by hand. I guess that there is a better solution for this problem, but so far I did not find it.

As it has atomic commits, theoretically it should not be too hard to make Subversion roll back the last revision, and that functionality would make it, from my point of view, very close to an ideal version control system. I would certainly recommend evaluating it if you are shaking up the current version control, or starting a new project.

Image credits: Sick 31/SXC

Looking back, the .Net developement landscape is far from ideal – our choices left us with a working environment, and enabled us to get the job done, but with a lot of bumps on the road. From my perspective, .Net is still three or four years behind Java in terms of platform maturity and available tools for enterprise application development. The core development concepts are there, but .Net lacks the support which Java has with a vast number of independent enterprise frameworks, servers and libraries. A lot of popular Java libraries and tools have been ported to .Net, but are often much less stable, or complete, than the originals. But, even though they do not shine brightly yet, there are some rising stars.

Development tools

The standard development IDE for .Net seems to be Visual Studio. I became test-infected about five years ago, and would not give that up for anything, but Visual Studio offers integrated unit testing only in the Team Suite version (the company had only a Professional VS license, so the IDE had no unit-test support). NUnit performed quite well for our unit testing requirements, but it had to be run externally, and there was no click-on-exceptions-inspect-code support, which I got used to in Eclipse. Also, VS can perform only basic refactorings, and for me good refactoring support is one of the fundamental features for a modern IDE. So we tried to find a replacement.

Improve C# plugin for Eclipse offered content-assistance only for C# keywords, without even trying to fetch method names or parameters with reflection, so we quickly discarded it. We then tested Sharp-Develop, an open-source IDE for C# – which offers NUnit and NAnt integration and VS project-file compatibility. However, it is still in an infant stage – it simply had too many bugs and did not offer enough customization to be useful on this project. I see big potential in Sharp Develop, and really think that it can become the Eclipse of .Net if more effort is put into it, but it was not for us at this time. As bad as Visual Studio is as and IDE, it is still the best there is for .Net.

As we could not find a replacement for VS, we looked for a way to improve it. It seems that we were not the only ones with the same problem, and JetBrains tried to cash in on the ‘unhappy eclipse developer in .net world‘ market. They offer a plug-in for Visual Studio which makes it more Eclipse-user friendly, called Resharper – it’s not free, but not too expensive either (200 USD). It offers NUnit and NAnt integration, a decent set of refactorings, search and navigation improvements, and after testing the free version we decided to buy about twenty licenses. On the end, it turned out to be a sweet and sour mix – it significantly slows down Visual Studio, leaves crap files in the project source (even if you tell it five times to save it’s cache in system temporary folders), and reports false compile errors when a DLL project reference is removed. Some refactorings don’t work correctly, especially looking for interface references. Several of our developers have uninstalled it, since it has too many bugs. I still use it, because the basic Visual Studio refactoring set is just not enough for me to do my work, and I live with the false compile errors and take care when checking-in files into CVS, but I am far from happy.

For the build scripts, we decided to use both MSBuild and NAnt on the end. NAnt scripts are much more readable and maintainable, which is important for packaging, so we decided to keep using MSBuild for development, but use NAnt for packaging. Although that means doubling the effort to write build scripts, we have both the benefits of IDE-integrated build and flexible packaging.

For integration and acceptance testing, we use FitNesse. FitNesse .Net integration was a bit tricky to set up, and we had to hack the code to get it working with nullable types and correct a few other minor bugs, but it is now an indispensable tool for our project. It can test both Java and .Net code and cut through technological boundaries. Together with Selenium it can even test the system end-to-end – populating Web fields and submitting forms, then checking the results in the database.

Version control

The standard version control system in a .Net environment is Visual Source Safe. But that crap was never, as far as I am concerned, a proper version control system. It cannot recognise a modified file unless it was checked out, and works properly only on a LAN. Visual Studio 2005 has a new source control system, but that’s supported only in the Team Suite version, which the company did not have. Source off site solves the remote access problem for VSS, but this project has a mix of technologies and it was really important for us to have the version control working properly, and not get in the way, even without Visual Studio. Good-old CVS was installed on a Linux machine, but Visual Studio (of course), did not support that out of the box. We tried the Igloo Visual Studio plugin for CVS, but it simply did not live up to our expectations – it lacks support for some basics like visual notifications of changed files, and requires too much manual work. Tortoise CVS is an interesting solution for the problem – it is a free CVS plugin for Windows Explorer, which enables you to check files in and out of a CVS repository from the folder window. It has a few quirks, especially disconnecting and re-connecting to CVS for every folder, but it works good enough. Some developers actually use Eclipse even for the .Net source-code control. So, we still lack version control-IDE integration, but it’s the lesser of two evils.

Application framework

Comming from a Java-centric environment, my first stop were ports of ‘standard’ Java frameworks and libraries – Spring.Net and Log4Net. Spring.Net turned out to be, at least six months ago, just a glorified configuration engine. It lacked any notion of a proper MVC web framework, which was crucial to the project, and with all it’s dependencies, it was a bit too heavy for just an IoC configuration loader. We decided to use Spring.Net for dependency injection, and write our own MVC, but then it all fell apart under heavy load. Spring.Net depends on Log4Net, and Log4Net turned out to be a big risk – under initial stress testing, when the services crashed, we lost the last few log entries (which were, considering the situation, the only ones important). We spent some time trying to make it flush logs after each entry, without success, and just gave up. So using Log4Net, and with it Spring.Net, was out of the question – there was no point in having two log engines in the same project, and Spring.Net could not use anything else.

My next stop was Microsoft Enterprise Library, a collection of free add-ons to the .Net framework intended to provide standard services. Among the ‘application blocks’, which is Microsoft’s name for components, we found a proper logging engine. It performed OK under heavy load, and had an API similar to Log4J, so it was a serious candidate. Digging through the code we found that the Enterprise Library actually had an inversion of control engine (called Object Builder, later released on CodePlex), but it still left us without a good Web MVC system. We had some doubts about Object Builder license, but if the Enterprise Library had a good lightweight MVC, we would have probably used it.

Meanwhile, we experimented with some other logging frameworks, and NLog passed all our tests – in addition to performing well under heavy load, Log4J-like configuration and API, it also had a fairly flexible appender support (NLog calls them targets), and can add contextual information to log entries.

Then we found Castle Project, a lightweight application container intended to be a mix between Ruby’s flagship application Rails and Spring Framework. It has a good inversion of control engine, and a proper lightweight Web MVC. Castle is very open to integrations, so it can use NLog in addition to Log4Net out of the box. Although the framework is still a ‘release candidate’, it works stable and did not give us any problems. The configuration files are very similar to Spring, and Castle tries to resemble Spring in other areas, so the learning curve was quite short for us.

Castle’s Web MVC is configured partly in code and partly in external files – things like aspect-like filters and web folders, which Castle calls ‘areas’, are configured as class attributes rather than in configuration files – which significantly limits re-use of MVC controller code. I would really like to see this moved to external files, but other that that, Castle MVC works quite fine. It can use several rendering engines, including NVelocity, Web Forms and Brail (templates in Boo). It does not currently support XSLT, but has a pluggable rendering architecture, so I am still thinking about whether we should write that plug-in ourselves. Meanwhile, we use NVelocity with great success.

Rising stars

Many Java-to-.Net ports are still unstable or several years behind their older cousins in features. But, I am very happy with NAnt, NUnit, NLog and NVelocity, they seem to have reached the point of production quality. Better VS integration would benefit NAnt and NUnit very much, and I’d like to say that Resharper is the solution for that, but it simply introduces too much problems as it is. I hope that it will get cleaned up soon.

Sharp-Develop is on a good way to become a serious competitor, especially if Microsoft keeps unit testing and code coverage as exclusive features of the most expensive Visual Studio version. I would like to see better customisation, less formatting bugs, more refactorings and CVS integration in Sharp-Develop.

Castle Project is very interesting – and I expect to see it gaining more and more support. Some parts of it need to get cleaned up, and it needs better documentation, but it is quite usable even now.

FitNesse is also a rising star of .Net space – it is a bit tricky to set up for .Net testing and lacks good .Net-oriented documentation, but once it’s running and you get a feeling what it can do, it works like magic. (I wrote a short introduction to using FitNesse with .Net which might help if you decide to use that tool.)

My conclusion is that it’s often necessary to dig deeper in order to get the right .Net tools – and not just use the port of a popular Java tool. On the end, here are two good places to start digging: csharp-source.net and www.codeplex.com.

Image credits: Vierdrie/SXC, Jessics/SXC.