Though I've been programming computers as a hobby since 1980, most of this was done on single machines by myself. Needless to say, I've lost work due to hardware failures, inadvertent deletion, and just plain "breaking" my working code. Ultimately, this created too much extra work and sweat.
In this article I'll describe how to transition from simply saving your code in folders on your computer, to using a revision control system which should safeguard your code and allow code "tinkering" without destructive or irreversible consequences.
While there are many articles about how to set up and use a source code control system, I found many were limited, dated, or uncompleted; or they dealt with a much larger team approach to coding. This article attempts to translate my lengthy research among this mire into a helpful article suited to those entering the year 2009.
For the purposes of this article, I'll assume the following:
- You are NOT independently wealthy (you do not have the capitol to invest in enterprise development solutions).
- You already have Visual Studio 2008 (not Express) installed and running on your Vista machine. (Where all your hard earned cash has been invested)
- You already have personal code you work with using VS2008 and are storing it on your computer. Perhaps some source code you found online and have modified.
The tools used for this project are:
- VisualSVN Server - SVN web server to handle requests across HTTP connections
- TortoiseSVN - Windows Explorer context-menu based SVN utility
- AnkhSVN - VS2008 SVN add-in utility
There are many alternatives to these tools. In fact, all three duplicate the majority of each other's SVN functions since all include "Subversion". I've chosen them for no particular reason, though all are freely available, seem to be in growing use, and support current software versions. I'd recommend going ahead and downloading a recent copy of each to be installed using the guidance below.
For the purposes of this article I'm using:
- VisualSVN Server v1.6.2
- TortoiseSVN v1.5.5, Build 14361
- AnkhSVN v2.0..5250.202
(Note: if you follow the pictures too closely, you'll notice my server name is "Dad", my Vista installation is on my I:/ drive using my H:/ drive for storage, and the project I'm using is the SourceOutliner powertoy available at CodePlex.com)
SVN Source Control Concepts
Before we begin, it's helpful to understand what we'll be doing and why we're doing it. Here's where my biggest struggle began. Perhaps you've already interacted with CVS or even SVN code repositories online at places such as SourceForge.net. But if you are like me, you didn't go any deeper than "checking out" code to download it to your computer and fiddle with it.
Though not the best example, a code repository is like the old "Briefcase" file on the Windows95 desktop (did anyone ever really use it?) The code repository is a storehouse containing the code files and all modifications to those code files, along with who modified them and their comments. Subversion (SVN) programs perform the interaction and record-keeping. Specifically, there are no folders or files within the repository when viewed using the file system. However when using a Subversion program, it accesses the repository and displays the database as if it were a file system.
The code repository is simply a database filled with records. It can be acted on via the local file system or remotely via HTTP. Therefore, an SVN Server is a web server that handles interaction with the code repository across HTTP and uses its built-in Subversion to track all changes. It also acts as a database server in that respect since it regulates tracking of revisions. The SVN Server is a portal through which all code file changes go in and out of the code repository.
And finally, TortoiseSVN and AnkhSVN are graphical interface utilities which contain Subversion and also allow interaction with an SVN Server instead of using command-line utilities. While TortiseSVN is integrated into the Vista file system (namely the Windows Explorer), AnkhSVN is integrated inside VS2008.
(Sidebar discussion: To reach the results of this project, the SVN server is not really needed, nor is TortoiseSVN once we create a repository with one of them. However, my goal is to acquaint us with how SVN works across the internet using remote servers. It just so happens for our project, our local and remote workstations are one and the same. Generally, every place we access the SVN server using https:// we could just as easily use file:/// and access a local repository on our computer or the Windows network.)
Setting Up the VisualSVN Server
First we'll make plans to install the VisualSVN Server on our Vista machine, then we'll install it.
I keep my personal source code stored in the default VS2008 "projects' folder found at "C:\My Documents\Visual Studio 2008\Projects." This is not going to change.
Next we must choose where we'll host our code repository. Though I'm breaking rules by keeping all this on the same computer, I'd at least recommend your keeping the repository on a separate partition or separate hard drive. (Even better yet, on a separate Win32 box using it as a file server, but that's beyond the scope of this project). We'll use "D:\SVNRepository"
Then we must choose what type of security we'll use, it has two parts. Since the SVN Server is a web server, the first part we must decide is if we want a secure connection to the svn server (https://) including how to avoid conflicting with an existing IIS7 web server. We'll go with a default secure connection using the default settings which can be changed later. For the second part we must decide how users authenticate with the server. We'll choose windows authentication since its better integrated.
Now's the time to install the VisualSVN Server using the details decided above.
When the installation is complete, you should have the VisualSVN Server Manager displayed. Before we can actually access this server, we'll first need to add some users. Right-click on the "Repositories" item in the left pane and select "Properties." Add our user name with read/write permission. We also might want to add "Guest" read only permission.
Next we'll create a code repository which is a folder inside our main repository. In our case, we'll use a single repository to store all our projects by a project name folder. We can always add or reorganize later. We can either right-click on the "Repositories" item in the left pane and select "Create new repository..." or choose that item if it's displayed in the main right pane. We'll name our repository "Main" and there's no need to create a default structure at this root level, we'll do that inside each of our projects (my layout preference)
If everything has gone well, at this point we can see our SVN repository. We can right-click on the "Repositories" or "Main" items in the left pane and select "Browse" or click on the Server URL if it's displayed in the main right pane.
For now, we've completed setting up the VisualSVN Server.
Setting Up TortoiseSVN and AnkhSVN
At this point we'll install our two graphical interface utilities. Try not to worry about the "Vista" warning when installing TortoiseSVN and just do it.
Next we'll check to see if AnkhSVN is set to work with VS2008. Launch VS2008 and select "Tools", "Options" then the "Source Control" settings. The Current source control plug-in should be AnkhSVN. If not, drop-down the list and select it. Again, if you're a fan of WinMerge, you could set it up under Source Control-Subversion. Well stick with the default AnkhSVN utilities.
Importing your code into your repository
So, if we've been successful at following up to this point, we have a running SVN server, a remotely accessible local repository, and a VS2008 interface. However our personal source code is still just sitting in our projects folder awaiting destruction from hardware failure or undisciplined code changes.
This next concept was the second biggest hurdle for me to overcome. Thankfully AnkhSVN automates most of the lengthy steps you'd find elsewhere on the web. We will continue to work with our code from the same location as we always have. However, we will begin using the SVN repository as a backup and revision management facility.
Inside VS2008, open our source code project as always. Next, in the Solution Explorer, right-click on the solution name select "Add Solution to subversion..." We'll need to use an SVN server path which includes the repository name. In my case it's https://dad:8443/svn/Main. Anything less, and it won't find the server. Select "svn/Main", and check off "Add trunk Folder for project". Refrain from creating a new folder or selecting a project already within the repository unless this is a subproject. After clicking "OK" we'll be asked for a log message, I'd suggest "Initial import into repository." We've successfully preped the project for inclusion into the repository. Note a slew of icon glyphs (yellow and blue plus signs) have been added inside the Solution Explorer.
Although the VS2008 "solution" is connected to the repository, the VS2008 "projects" inside the solution are not. In the Solution Explorer, right-click on the solution name select "Add Selected Projects to subversion..." We can connect or disconnect the solution or projects from subversion using the "File", "Subversion", "Change Source Control" menu item.
Now wait! You'd think we were done at this point...however, we're only halfway to actually adding our project to the repository. Go ahead and browse the repository. Our new project is NOT there. We've turned on source control features within our VS2008 project, but not committed it to the repository. This is actually a "feature" not an added step. What we do inside VS2008 doesn't have to affect our repository. Go ahead and exit VS2008 saving your work. As a learning point, this is what we'll be doing in the future. That is, modifying our "working copy" as we've always done. We're not required to update the repository with EVERY minor change. Restrain yourself if necessary!
Go ahead and re-launch VS2008 and open our project. Everything is as we left it! To import our work into the repository, we must "commit" it. Open the "Pending Changes" window at the bottom. You'll see the list of "changes" not yet acted on. Also notice the "Commit" and "Update" buttons at the top left of that window. These will become our most used SVN friends in due time.
- "Commit" adds changes we've made to our working copy into the repository as a new revision
- "Update" attempts to update our working copy to the latest version in the repository
We'll deal with possible conflicts between our working copy and the repository in another article. For now, we know our project is not yet in the newly created repository, so click the "Commit" button to import it there. Notice all the files listed in the pending window disappeared and the "Commit" and "Update" buttons are no longer enabled. Congratulations, our working project is in sync with the repository. Verify this by browsing your repository. We may have to refresh the page or management console to get it to display the updates. If we browse our project's working folder in Windows Explorer, we should notice the files and folders now have glyphs similar to what's inside VS2008 thanks to TortoiseSVN. We'll also notice "_svn" folders containing our local source code control information.
We've gotten SVN up and running locally and learned how to adapt VS2008 projects to SVN source control. In part II, we'll learn how to work with changes to our source code and how the repository can be our friend.
In summary in this article we:
- We installed an SVN server and utilities
- We created a local SVN repository which can be accessed remotely
- We added Source Control features to a programming project and then added it to our SVN repository
Tweaking your setup
Since VisualSVN Server is a graphical interface to a Win32 version of the Apache web server, we can easily modify the configuration.
To tweak the SVN browser display and allow easy interaction with TortiseSVN and Windows Explorer, see this article: Customise VisualSVN Server browser view On your Vista machine you will need to install the WebFolders feature and set up a "Network Place".
Credits and References
Here's some additonal references to better understand and use SVN.
- Nov 24, 2008 - Removed note to change TortoiseSVN setting since it only applies to VS.Net 2003.
- Nov 22, 2008 - Began working on my first article for CodeProject. it may need corrections to add additional steps when installing on a clean machine.