A lot of times when starting a new project you get fairly far into coding before realizing that you might need tools like source control or a flexible build system.
This article will outline what is sometimes called “Iteration Zero,” which is the step in which you setup your development environment.
Keep in mind that these are just suggestions (by me) for a healthy project environment, not a cure-all for development. Each team will (should) have a unified process that everyone agrees on. Hap-hazard development with little support for teams can put a burden on your developers and put the project in jeopardy.
Step 1: Choose a source control provider
Even when doing pet-project and single-man projects, you need source control. Let me repeat this. You need source control. There are many to choose from, and they are generally easy to use. I personally use Subversion. It is free, comes with a ton of features, and is easily used through the right-click explorer icons. I would warn against Visual SourceSafe for large projects, but for smaller projects it’s not that bad and is tightly integrated with Visual Studio. I’d recommend Subversion (or SVN for short), CVS, or Perforce (which is not free). This article will focus on SVN, since it is what I use most.
I typically create a sandbox folder, where all projects under source control reside. Here’s a look at my current sandbox:
As you can see here, I have about 5 projects, with various icons on the folders indicating their status. This is provided through TortoiseSVN, an explorer shell add-in. TortoiseSVN adds these context menu items you can see here where I right-clicked on the screen. From here I can checkout projects that reside in the subversion repository.
On projects with distributed teams, you can install Apache and use a WebDAV module to allow HTTP access to the repository. As long as you use SSL and a password file, you’ll be secure. There is a free online book available here that has some good information on how to set this up.
So I’m going to navigate to my subversion folder (NOT my sandbox) and create a new repository for our sample project. Let’s call it FinanceAssistant. First, we have to create the directory that will hold the repository. Next, I right-click on our new folder and select “Create Repository Here.”
Here you have a choice between a Native File System and a Berkeley database. I have heard that there are no real advantages to using a BDB, though there are some constraints. Just about everyone suggests using a Native File System repository. Once this is complete, your repository is ready for checkouts.
The next thing I suggest is to create three folders:
/trunk/ /tags/ /branches/
This is a crucial step in effectively utilizing the power of a source control provider. Basically all of your development goes underneath the trunk folder. When you think you are ready for a first-release to your customers, you can Tag the release, which will basically take a snapshot of the current state of the project and stick it into a folder underneath the tags directory. If any bugs are found in the tag release, then they are fixed and merged back into the trunk so future versions get the fix. If any experimental development goes on (like upgrading to a new 3rd party dll version, or some major re-work or refactoring) then you can branch the project. This avoids the problem of having one developers experimentation negatively affect the entire team. Here's how our project might look:
/branches /ExperimentalBranch1 /tags /0.4 /0.64 /0.85 /1.0 /1.4 /trunk /src
What's great about this approach is that you can, at any time, checkout a specific version of your project that may have been in the past. Everything that was included in source control will return to the state it was in at the revision you specify. This can really help at times, especially if you have customers using old or different versions of your software and are reporting bugs. The first step is to create the three base directories. Let’s do this via the Repository Browser in TortoiseSVN. Right-click anywhere in explorer and go to TortoiseSVN->Repo-Browser. Enter in the path to your repository, which in my case will be this: file:///e:/svn/FinanceAssistant/ (notice the unix/web style path)
. From here I can create the folders that I talked about. Once I have them created, I am ready to check out the trunk to start developing. You definitely don't want to have this entire structure checked out at once. You might inadvertently modify a file that isn't under active development.
I’ll now go to my sandbox folder and checkout the project by right-clicking explorer. Notice how I’m checkout out the trunk subdirectory, not the root of the repository.
There are many options to choose from while checking out a project. Here I can choose a specific revision # to checkout from. This is good if a developer checks in some breaking changes and you need to roll-back to a revision that was working.
This will create the working folder in our sandbox. You’ll notice that any directory under source control will have a hidden folder called “.svn”. The period in front of the svn wreaks havoc with FrontPage Server Extensions with Visual Studio 2003. ASP.NET 1.1 projects will need to look for a specific version of TortoiseSVN that uses a “_svn” directory instead. For Visual Studio 2005 we don’t have this problem.
So now we have our working folder, ready for development. After we make changes to the contents of this folder, we must Commit the changes. When we want to get the latest changes from the server, we Update our working copy.
So at the beginning of every day, we should Update our working copy to get the latest changes. We then will make changes until they are stable and pass tests. After this we Commit the changes so that other developers receive them. It’s important not to let your project get too out-of-sync with the repository. It is worse, however, to commit changes that break the build and prevent other developers from being productive. If any two files are modified and checked in at the same time, subversion will do a simple merge and ask the developer to verify the changes using a Diff Viewer.
Using a source control system is a critical step that many small shops just don’t do. The risks are enormous if a disk fails or if developers overwrite each other’s changes.
Here are some more resources on using Subversion:
In step 2, we’ll take a look at a slightly different project directory structure than you’re probably used to. We’ll also talk about NAnt as a build tool to support this structure. Until next time….
I'm Ben Scheirman. I am a .NET software developer with a strong interest in agility. I work as a Principal Consultant with Sogeti.
Read more here.
email me
Ads by The Lounge
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.