Last week, our team made the decision to start using Subversion. Previously we had been using CVS – sort of. Some of our team were actually using Visual Source Safe, and then checking in their code every couple of days to CVS. In addition, we had no real development tree in CVS. Our network admin had set up a Subversion server, but other than that, no one really knew much about Subversion, or, as it turns out, source control systems in general.
I got tasked with getting us up and running, mostly because I’ve been pushing us hard to use CruiseControl.NET so we could do automated builds from source control. It was an interesting road, and I finally got it up and running and wanted to capture some thoughts from the process.
First, you need to get a repository running. Creating a repository and accessing it is fairly straightforward. Grab the latest Subversion package and install it. Then from a command-line run
svnadmin create C:\Path\To\Repo. This will create an empty repository at the location you specified. You can make sure it worked by typing
snv list svn://machine/Repo. So, for example, if you wanted to put your Repositories in a folder called Data on your C drive, and your wanted to name it Projects, you would run:
svnadmin create C:\Data\Projects
svn list svn://localhost/Projects
At which point you would just see a blank line returned.
Now that you have the repository set up, anyone can access it by doing the svn list command from a remote computer. Of course, they can’t do anything with it, because you have to set up security. Within the directory of the repository you just created, you should see several new folders, including one called “conf”. Go into it and modify the svnserve.conf file to look like:
anon-access = none
auth-access = write
password-db = password.conf
Now, create a password.conf file in the same directory which should look like:
user1 = user1pw
user2 = user2pw
user1 can log in to the repository using the password
Second, you have to decide how easy you want to make it for people to add new modules and check in and out files. We settled on a VS.NET plugin from PushOk software. I had used their CVS plugin, and it worked well. The Subversion one so far has worked well – I found that at first I had to disable my internet security firewall, but before I had a chance to sniff around and find out why that was blocking it, it began working. There is also TortoiseSVN which adds a context menu to Windows Explorer.
Now, with the ability to create a repository under your belt, and a way to access it, you have to figure out what kind of structure you want your development tree to look like. This was the hardest part for us, because we have three lines of business that have several projects going on underneath them. Add to that the concept of branching, tagging, and a development line, and it was a bit confusing.
We finally decided to create one repository for each line of business. This was a two-fold decision. One, it allows us to eventually limit access to the repository to just those developers working on it. Second, because Subversion uses global revision numbers, we won’t see projects bump up 80 or 90 revision numbers between checkins. An example repository looks like:
| | |-Laptop
| | | |-Jurisdictions
| | | | |-Juri1
| | | | |-Juri2
| | | |-SharedLibraries
| | |-WAP
| | |-Jurisdictions
| | | |-Juri1
| | | |-Juri2
| | |-SharedLibraries
This setup allows us to have a main development tree, while allowing us to tag certain builds as nightlies or as releases. We will be using CruiseControl.NET to automatically checkout, build, and tag code. In addition, if we need to branch off part of the code (say, for a UI refactoring), we can do that without stopping work on the main development tree.
One thing that was incredibly helpful to me was _Version Control with Subversion_ which is available as a book, or a download from http://svnbook.red-bean.com.
Now that we have the initial setup, it will be interesting to see if everything folds out the way we think it will. I’ll keep this blog posted as we tweak things.