We all know that Microsoft is an evil company, right? Their source control / project management software should be no exception to the rule that everything they do is for their own benefit and to make them money. Attention getting first sentence jokes aside, (I was kidding btw) I hope to give a rough overall comparison of Team Foundation Server, (TFS) as it compares to Subversion (SVN, specifically I’ll be covering the Tortoise SVN client for windows) for source control, and project management, from the lowly developer’s perspective at least. Personally, I am only a developer, and don’t have to worry with anything more than modifying code, checking it in, and ensuring that my changes are applied to the correct branch of the product. The higher level project management, build automation, and branch operations occur at our team lead, and project lead levels which I only have a rough understanding of, so on these points I can only speculate. I offer these comments only as my opinion on things that are particularly note-worthy. There are certainly more factors to consider when choosing one product over the other.

Subversion (SVN)

First up, SVN using the Tortoise SVN client on windows. SVN is the first source control system I used as a developer, and as such, has a soft spot in my heart reserved for it. SVN is simple to understand, configure, and the Tortoise SVN client integrates well into the Windows Explorer shell. The basic features of Tortoise SVN are floated to the top level of the interface, but there are many levels to it that I have never dived into, and as such, I can’t comment on. What I can say however, is that I like the elegant simplicity of the integration into the windows shell, but this integration becomes a pain when there are a rapid succession of releases, most of which require a reboot to apply.

SVNShellIntegration

In any folder that contains either the “.svn” or “_svn” directory (depending on your “Settings –> General –> Subversion” settings) Tortoise goes to work in detailing what files and folders are part of SVN, whether they are modified, new, etc. or none of the above via the overlay icons. The red icon indicates that a file in the folder has been modified and will be added to the list of files that appears when I run SVN Commit. All of the SVN commands are made available via the right click menu by Tortoise:

RightClickMenu

One of my favorite features is that the context menu can be modified. Right Click in any empty space in windows explorer –> TortoiseSVN –> Settings –> General –> Context menu will show you the dialog below:

Diff

<p>In each installation, one of the first things I do is to enable the “Diff” command to appear at the top level of the context menu. This allows me to right click any modified file, and select “Diff” and the Tortoise file comparison tool is launched and compares the local file, with the file stored on the server.</p>  <p><a href="img/TortoiseMerge_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="TortoiseMerge" border="0" alt="TortoiseMerge" src="/img/TortoiseMerge_thumb.png" width="749" height="438" /></a> </p>  <p>TortoiseMerge is my current favorite file comparison tool, and is built into the Tortoise SVN client. Whenever you select the “Diff” option from the context menu, the diff viewer configured via Tortoise SVN is launched, and the files are compared. On the left side is a gray area indicating the currently viewable section of the file. The yellow highlight indicates the changed portion of the file. From the side, I could click and drag the gray area to any other portion of the file, to allow me to quickly jump to a section of the file that I know to be of interest. This feature is similar on other file comparison tools as well, and it is of note to mention that the Tortoise SVN client allows the user to change which tool he uses to compare files. Personally, I like TortoiseMerge so much, I’ve never needed anything more than this.</p>  <p>An interesting note: If you have two files in the same folder you’d like to compare anywhere on your system (not just in an SVN folder), you can also use the integrated Diff command to compare them. Simply select both files in windows explorer, then Right Click on one, and select “Diff”. The TortoiseMerge diff viewer displayed above launches and will compare the two files selected in windows explorer.</p>  <p><a href="img/CommitDialog_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="CommitDialog" border="0" alt="CommitDialog" src="/img/CommitDialog_thumb.png" width="394" height="443" /></a> </p>  <p>The commit (check-in) dialog is displayed whenever you are ready to check-in your changes to the server, and allows you one last opportunity to compare your files to see that only your changes are committed to the server. Making this step a separate operation outside of the Visual Studio IDE I think is an important step in preventing unwanted code in the source tree, and helps to prevent accidental check-ins. However, it is understandable when checking in lots of files that one gets easily lost somewhere on the bottom of the scrolling view of files, and is accidentally checked in anyway. </p>  <p>The comment box of this dialog will provide spell checking (necessary for me as I am an awful speller) and intelli-sense that will provide hints for the files and folders that exist in the current directory. (I’m not sure of all the rules in place, but the intelli-sense is nice sometimes, but often gets in the way too) The recent messages button will supply recently entered comments that can be auto-populated in the case that you get open this dialog, start typing your commit message, then forget something and have to add / modify the files being checked in. It’s a nice feature for Tortoise considering this dialog isn’t always visible like the “Pending Changes” window is for TFS.</p>  <h1>Team Foundation Server (TFS) – Source Control</h1>  <p>As I prepared my notes for this post, I realized that there are a lot of things that TFS does that SVN does not, so this post may not even be a fair comparison. However, I believe I can start with comparing the bits that are similar between these two, then move into everything else that TFS does, be it for the better or not.</p>  <p><a href="img/SourceControlExplorer_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="SourceControlExplorer" border="0" alt="SourceControlExplorer" src="/img/SourceControlExplorer_thumb.png" width="590" height="339" /></a> </p>  <p>The TFS interface is integrated into visual studio, as opposed to being a separate interface outside of visual studio. Above is the trunk of our source tree. We have branches in the /Releases folder, one for each version we’ve released. A similar structure is easily achieved with SVN as well, but my personal projects haven’t gotten to the size that I’ve needed branches yet. </p>  <p>One of my pain points with the integrated nature of TFS is that the files on my local disk are locked by the operating system itself. Meaning, that if I navigated to my source directory opened a file with notepad or some other editor besides Visual studio, I would not be able to save the file directly, I’d get locked out of the file until I checked it out from TFS. The biggest example of this is generated code. Whenever I generate our entities (because I’ve added a field, proc, etc.) I have to make sure I first check out the file I want to modify in Visual studio Source Control Explorer, then copy –&gt; paste the files into the appropriate directory. (Alternatively one could drag –&gt; drop the file from Windows explorer into Visual studio, but I’ve found that this checks out the project as well as the file, which is undesired since the file already exists in the project, and the project file need not be checked out) </p>  <p><a href="img/CheckOutDialog_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="CheckOutDialog" border="0" alt="CheckOutDialog" src="/img/CheckOutDialog_thumb.png" width="451" height="289" /></a> </p>  <p>If I start from Visual studio, and start editing a source file that I want to modify, or even if I open a WinForms form with the Designer, I get the above dialog to prompt me to check out the file for editing. (The VS designer automatically will generate code, or slightly modify existing code thus causing data to be written to the file on disk, and having any data written to the file, even if it’s the same data, counts toward TFS believing it needs to check out the file) Personally, this only serves to get in the way when it comes to editing code. It’s one more dialog to click through, and interrupts my flow of consciousness. This dialog can be turned off however, (<a href="http://www.woodwardweb.com/teamprise/disabling_tfs_a.html">Enable / Disable automatic checkout</a>) which was my first step when setting up my new work machine. Even without the dialog appearing, VS has to hesitate so that it can notify our TFS server that the file is checked out, and there is a noticeable pause before my keystrokes appear on the screen. This does only occur on the initial check-out, subsequent edits occur normally, but still, the initial check-out is quite obtrusive. </p>  <p><a href="img/CompareFile_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="CompareFile" border="0" alt="CompareFile" src="/img/CompareFile_thumb.png" width="436" height="243" /></a> </p>  <p>Checking-in is nearly identical to SVN, with the main difference that one cannot change where the “Diff” function occurs on the right click menu. Always we have to go one submenu deep to compare, and more than a few times I’ve chosen to compare to the wrong version (Checked-in vs Workspace, vs Unmodified) and had to execute the menu maneuver again. Since, as a general rule I review all code I’m about to check-in, it becomes a chore to review all files one-by-one.</p>  <p>Since TFS automatically checks out files that I may not have end the end modified, instead of looking at the file in the Pending Changes window, and performing the previously mentioned Right click –&gt; Compare –&gt; With Latest click, I run first a TFS power toy that will automatically un-check-out any unmodified files in my local source tree. The command is part of the TFS power tools installation, it’s called <a href="http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx">Undo Unchanged</a>. (scroll down to see this option) It’s a must-have for any TFS developer.</p>  <p>Finally, the built-in file comparison tool in VS (or TFS, not sure which is to blame) is a joke. <a href="http://blogs.msdn.com/jmanning/articles/535573.aspx">James Manning has a post</a> detailing how one can change the default comparison and merge tool to several others. (WinDiff, WinMerge, Beyond Compare, TortoiseMerge, and more) I strongly recommend you chose one of the alternatives. Personally, I use TortoiseMerge, but I think after a point, they all share the same set of features, and TortoiseMerge is free and open source. (picture above in the SVN Section)</p>  <h2></h2>  <h2></h2>  <h2>&#160;</h2>  <h2>TFS For Project Management</h2>  <p>Up to this point, I’ve been comparing the same feature sets between TFS and SVN. These also happen to be my biggest pain-points with TFS, and unfortunately these features account for roughly 80-85% of my interface with TFS. I can only hope things get better in future releases. From this point on however, I will briefly (very briefly, this post is becoming a book) mention some other features TFS has, and say that it seems to do these well.</p>  <p><a href="img/Shelve_Dialog_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="Shelve_Dialog" border="0" alt="Shelve_Dialog" src="/img/Shelve_Dialog_thumb.png" width="375" height="278" /></a> <a href="img/Unshelve_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="Unshelve" border="0" alt="Unshelve" src="/img/Unshelve_thumb.png" width="357" height="278" /></a> </p>  <p>Shelve sets are probably one of my favorite features of TFS. Essentially it allows one to store a copy of his code on the server, without checking in the code, and he can undo local changes in order to test something else in the interim. Also, if I shelve something, other developers can search for items I have shelved, and download that code to their machine. This allows one to do a sort of pre-alpha alpha test before the code is even checked in. Very clever.</p>  <p><a href="img/NewbugForm_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="NewbugForm" border="0" alt="NewbugForm" src="/img/NewbugForm_thumb.png" width="384" height="270" /></a> <a href="img/WorkItems_4.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="WorkItems" border="0" alt="WorkItems" src="/img/WorkItems_thumb_1.png" width="449" height="133" /></a> </p>  <p>Each developer is assigned work items, and can create new TFS work items. A work item can be any of (but not limited to) the following: Bug, Change Request, or Task. This allows a developer to create a work item for each bug, and check-in the exact code he used to fix that bug. All change sets (check-ins) are associated with that work item at time of check-in, and can bee viewed under the “Links” tab. Later, when one is reviewing code, he can right click anywhere in the source file and chose Source Control –&gt; Annotate, and see the exact work item associated with that line of source code. This is obviously useful for tracking the original developer, when code was checked-in, and what the bug of origin was when the developer made the modification. (Note: SVN –&gt; Blame is very similar to this, but TFS allows a developer to right click on a specific line, and the Annotate window will open to that exact line since presumably it is of interest. Screen shots show below exemplify this)</p>  <p><a href="img/Annotate_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="Annotate" border="0" alt="Annotate" src="/img/Annotate_thumb.png" width="347" height="260" /></a> <a href="img/AnnotateWindow_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="AnnotateWindow" border="0" alt="AnnotateWindow" src="/img/AnnotateWindow_thumb.png" width="407" height="252" /></a> </p>  <p><a href="img/TeamExplorer_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="TeamExplorer" border="0" alt="TeamExplorer" src="/img/TeamExplorer_thumb.png" width="147" height="407" /></a> </p>  <p>Often times I need to look back to find a specific work item I worked on previously. TFS provides an interface that I can query on virtually any field that a work item contains within it. Obvious uses are tracking all tasks assigned to a specific release, or that contain a specific phrase when researching the first instance of a bug.</p>  <p>Also noted in the above screen shot, we have three automated builds setup. I consider these our sanity check to make sure we haven’t broken anything. These builds download all source files, compile the code, then run all our unit tests against the most recent check-ins. </p>  <p><a href="img/AutomatedBuildResults_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="AutomatedBuildResults" border="0" alt="AutomatedBuildResults" src="/img/AutomatedBuildResults_thumb.png" width="481" height="441" /></a> </p>  <p>Each build creates a summary report that we review after the build completes. Generally I only review it when it fails, since I may need to fix a unit test, or have inadvertently check-in code that causes a breaking change in another assembly that I didn’t test.</p>  <p><a href="img/UnitTestCodeCoverage_2.png" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="UnitTestCodeCoverage" border="0" alt="UnitTestCodeCoverage" src="/img/UnitTestCodeCoverage_thumb.png" width="629" height="236" /></a> </p>  <p>The build summary also includes unit test results for code coverage by assembly, and number of tests passed or failed.</p>  <h1></h1>  <h1>Summary</h1>  <p>SVN: </p>  <p>1. Keeps it simple while still providing a robust set of features</p>  <p>2. Provides a separation of concerns, so that it causes fewer daily pain-points. Note that pain points do still exist, but they aren’t part of my daily work flow. (e.g. sometimes the SVN folder needs to be "cleaned-up" and the "Clean-up" command doesn't always work)</p>  <p>3. Easier management of open source projects: <a href="http://haacked.com/archive/2007/03/02/A_Comparison_of_TFS_vs_Subversion_for_Open_Source_Projects.aspx">Phil Haack on Open source projects source control</a></p>  <p>4. It’s free</p>  <p>TFS:</p>  <p>1. Includes enough features to provide an entire project management suite</p>  <p>2. Tying together work items, with source code, with comments from developers, plus history of when everything occurred makes putting together timelines easy.</p>  <p>3. Shelve sets</p>  <p>In the end, I prefer SVN because of it’s ease of day-to-day use, and it’s price tag. It follows the principal of “do one thing, and do it well.” TFS attempts to be a “jack of all trades, master of none,” but it does bring some interesting features into play that I do find useful.</p>