UPDATE:
I have lately become disenchanted with the source control combination noted in my earlier post: A Random sampling of tools I use with VS2005 when coding web pages.
Since writing that post, I have experienced various issues with the Visual Studio integration, one of which cost me a week-and-a-half of development time and countless posts to the March Hare CVS support mailing list. I at first suspected the problems were caused by the tool I purchased on-line to provide the VS integration with CVS (see my earlier post for details); but it soon transpired that dropping to the command-line, and issuing CVS commands directly, did not solve the issue. After much research, I have come to the conclusion that the instability issues I, and many others, have experienced, are due to problems with Microsoft’s Visual Studio Source Control API. My experience, and that of many others, has been that any tool that is written to use this API is going to suffer from the types of problems I encountered- such as newly "Added" files vanishing upon first check-in/"Update", inability to check out files which I *know* are there, etc.
As a result, I spent some time re-assessing my whole Source Control "stack". I limited my choices to those that were either fairly inexpensive or free, with a bias toward open-source solutions. I am not willing to drop thousands of dollars on a Source Control system that is not open-source, for several reasons. First, while I *do* consider source control important enough to pay that much money, my experience has been that many problems with source control systems do not manifest immediately. If I am forced to dump a system that is not working after using it for six months to a year or more, I do not want to have to write off thousands of dollars in purchase or licensing costs on top of the loss of time and effort putting the system in place, dealing with problems, etc.. While open source is not a guarantee of quality, it can be at least a strong indicator. If the program is a popular one, and its project is active, many eyes have looked through the source for potential issues; and I can always look at the source myself to assess the quality of the code. Not to mention being able to locate and/or fix bugs myself!
After looking and asking around, and recalling good things I had heard/read about Subversion, another open-source source control system, and recalling an article I had read about a Subversion Visual Studio plug-in that didn’t use the Microsoft API, I decided to look into Subversion.
As I downloaded and installed it, I followed C# MVP Rick Strahl’s instructions in his article, "Setting Up and Running Subversion and Tortoise SVN with Visual Studio and .NET", in the July/August 2008 issue of Code Magazine, pp.58-69. Code Magazine’s website is unfortunately down at the moment, so I can’t give you a link to the article; but there is an older version of the article at Rick’s website: http://www.west-wind.com/presentations/subversion/.
[Note: there are a few typos in the article as published in Code Magazine; in particular, the command for setting up the Subversion server as a Windows Service is mangled, and caused me quite a bit of frustration. Assuming a default-location-install of Subversion, and that you will adjust the "c:svnrepos" part of the command to reflect the location of your repository, here is the proper command, which should all be on one line:
sc create svn binpath= ""c:program filessubversionbinsvnserve.exe" --service --root c:svnrepos" displayname= "Subversion server" depend= Tcpip start= auto
The spaces, and/or lack thereof, should appear exactly as shown. I have not checked the command in the on-line article linked above.]
Those of you who follow Rick Strahl’s Web Log on all things .NET: ASP.NET, AJAX, the JQuery JavaScript library, WinForms, ClickOnce, etc., know that Rick is an invaluable resource. Rick’s Blog is one of the first places I go for help when encountering a strange issue with .NET development. Particularly when doing ASP.NET work, if you’ve encountered a weird problem, if you’ve discovered that following the MS documentation to the letter does not achieve the proper result, if you’re looking for architectural guidance — chances are Rick’s been there, done that, fixed it, and Blogged the solution! Do yourself a favor, and get right over to his Blog. Read through the first page, then spend some time digging through the archives. You’ll thank me.
Note: you should always follow the Comments link to read the comments after each post, as they are often more informative than the original post. Many "movers and shakers" in the .NET community devour Rick’s blog on a regular basis, and their input is often the key to a solution. Either way, the dialogues between the commenters and Rick are usually fascinating…
I may do a follow-up post that lists blogs and sites I’ve found must-reads…
So, on my current projects, I am using Subversion in combination with Tortoise SVN, an interesting tool that actually integrates Source Control functions into Windows Explorer; and VisualSVN, a VS plug-in that, as noted above, does not use the Microsoft API. The VisualSVN Plug-In is actually a wrapper around TortoiseSVN, which is why both are required.
This should allow for a much more stable source control environment. Although VisualSVN is not free, it is inexpensive, and, if it works as advertised, it will be well worth the cost. The evaluation version is fully functional; it is time-limited and works for a month before you must purchase it. [Update March 16, 2010: I purchased the plug-in after a month and it has worked well ever since.]
As noted, Tortoise SVN uses the somewhat unusual idea of integrating into Windows Explorer. You open Windows Explorer and navigate to the folder that contains the local copy of your source. Files and folders that are under source control have an overlay on their icon which indicates their status at a glance:
If you have the latest version of a file or folder, a small green circle with a white check mark appears on top of the file/folder icon; a file/folder that has been changed since being checked out has a red circle with a white exclamation point in it, etc.
It is an interesting approach, and one that avoids loading a separate program for basic source control functions, which are available by right-clicking the file/folder and choosing an item on the context menu:
More advanced functions may require the loading of a dialog or window in order to, say, create a branch or tag, select a file, etc.
If you feel you need Visual Studio integration, as I do, or simply don’t like the idea of "shelling out" to Explorer for source control functions, the VisualSVN tool is the way to go. Among other advantages, it recognizes Visual Studio file types; so, for instance, you don’t need to Add your ".aspx.vb" or "aspx.cs" code-behind/beside files to SVN in addition to your ".aspx" files with the same names, VisualSVN will add them for you. VisualSVN realizes that the code-behind/beside files are related to the ".aspx" markup files, and simply "does the right thing". There is a free tool available, Ankh, but I had numerous problems using the CVS version with CVS, and it uses the problematic Visual Studio Source Control API.
VisualSVN places its own menu in Visual Studio, with much the same menu items as Tortoise SVN. In addition, it uses a system of colored bullets next to the files in VS’ Solution Explorer to show the Source Control status of each file in the solution. Also, you can do simple functions like Update and Commit from the right-click context menu of each file.
With this new system, it has been so far, so good, although I have not been using this combination for long yet. [Update March 16, 2010: everything is good so far and I’m a happy camper.]
As Rick Strahl notes, source control is only useful if it "just works" and doesn’t get in your way. Rick’s experience, and mine too, so far, has been that Subversion just works. If your source control system doesn’t just work, you will wind up, as Rick notes and I experienced, using source control for awhile, until you start experiencing problems; you will then stop using it, until one of the following causes you to try it again: optimism; your conscience/fear of catastrophe; a disaster that occurred when you couldn’t roll back to a working version; etc. This is an unhealthy cycle; source control only benefits you when you use it all the time, even on personal projects and projects that seem "too small to bother". When it just works, source control is a wonderful thing. It frees you from having to worry about breaking things when you make changes/write new code; it vastly simplifies continuing development on a released product; is a requirement when developing with a team; simplifies developing on more than one PC- i.e., your desktop and your laptop; and helps with version documentation (version change logs/histories). It can even work together with a bug-tracking system for even more power.
Andrew Cushen's Blog 