Subversion
As I have stated before a lot of things have been changing at my place of work. We have recently stopped using Visual Source Safe and moved everything over to Subversion.
The reason for the change was due to a number of bad experiences with VSS, including a number of important changes to code just simply disappearing and code being reverted without anyone telling it to. The main killer for VSS was the most recent project the team had been working on. The Visual Studio solution contained approximately 12 separate projects and each time the solution needed to be opened it took VSS several minutes to open up.
Why Subversion?
When the team decided it was time for a change we spoke to several other people and virtually everyone said SVN was our best option. The speed and reliability of SVN was the main factor for ourselves.
Converting VSS to SVN
The first step was to convert the VSS repository to SVN. A number of conversion tools were tried including this VSS to SVN converter, however they all came up with the same problem. It appears that there were a number of files within our VSS repository that were corrupted by not being checked in correctly.
The team discussed the problem and it was decided that we would simply import the latest version of all our project files into a new SVN repository. We have kept the VSS repository just in case we do need to revert anything back, but so far we’ve been fine. I would suggest in another few months we will be able to completely ditch the VSS repository.
One final step the team had to complete was to remove and VSS bindings from all of the project. The reason for doing this was to stop Visual Studio asking about VSS every time a solution is opened.
Using SVN
Setting up SVN on our server was a fairly straight forward process thanks to a 1 click setup program. After we had our repository in place we then installed an SVN interface tool on all of the necessary PCs. The great thing about this tool was the fact that the complete version control mechanics could be control through Windows explorer and we didn’t need to have Visual Studio open to update or commit any files.
The team did require a Visual Studio plugin for SVN to allow them to access the new repository directly. The Ankh plugin has so far done the job nicely.
Commenting
The team had got into a very bad habit of not making comments in VSS when checking files in, so it wasn’t always clear what had been changed in a file and why. As part of moving forwards the team has committed to adding comments to the SVN repository every time a file or series of files has been committed.
Benefits
Although the team has only been using SVN for a short period of time they have already noticed the following benefits:
- Much quicker opening times within Visual Studio
- No file locking, so several people can work on a given file at the same time
- Accessing the repository remotely
- Ability to view who changed what lines of code and when
- Easy and reliable backing up
- Works easily outside of Visual Studio
- Easy to have source control on all file types, which means we no longer have source control on just .Net projects
The Future
Now we have SVN fully up and running we are going to start looking at using CruiseControl.Net for continuous integration purposes. The will take the team a big step forwards and will help us to work with other teams remotely and with confidence.