Evaluating Source Control Systems

Or the other title - TFS Sucks Donkey Balls.
Normally I don't rave. I rant first, then rave. My first encounter with Microsoft's latest foray into whole product lifecycle management was as an unbiased review for moving my former employer forward off of Visual SourceSafe onto a new source control system. Well, not totally unbiased because SharePoint sucked ass at the time. Now I understand it sucks less ass in its current form, but still there is some ass suckitude. But I digress. Basically, TFS was a pig, required an entire dedicated machine, was slow as molasses in January, and all the whoop-de-do features like check-in policies and integrated unit testing and code coverage required a different, more expensive, and bloated version of Visual Studio. It also took me two or three tries to get it to install in a reasonably sustainable configuration.

Contrast that to Subversion which was very quick to setup, unobtrusive and required no additional hardware. We did later take a couple days to put it on Linux/Apache for stronger authentication and safer access, but that was not required to use the system (clearly, we went with Subversion - and never regretted it).

Here is an actually well balanced comparison of the two, while here is a Microsoft fan-boy comparison, if you don't want to hear me rave any more. My comparison grid is lower in this posting.

Now, a little over a year later I'm at a company that's using Team Foundation Server. You know what - its even more awful in a production environment than I thought it would be from my testing. Here is a relatively short list of complaints:

• It is slow. And I mean sloooooooow
• Merge tools are second rate
• It forces auto-checkout on you, even when configured with confirmation (just like VSS did)
• You can't share files among projects, and likely never will be able to do this without a 3rd party solution
• It performs phantom mystery checkouts of files unrelated to what you are doing
  
• If your TFS server goes down your developers will be all but unable to even open their solutions and do work
• TFS is unable to detect a changed file on checkin unless that file was explicitly checked out
• Non-Visual Studio users will be unable to make use of your TFS source repository (ex: designers)
• Just opening a solution causes TFS to reconnect to the server and attempt to refresh its file list - AND YOU HAVE NO SAY IN THE MATTER
• If a file gets deleted outside the Visual Studio environment, TFS will be unable to recognize this and a Get Latest operation will not recover the missing file.
  

Why is all of this true? Wasn't TFS a sign of Microsoft's recognition that VSS is, to put it mildly, and inadequate solution? Maybe originally, but then they placed the same joker who was in charge of VSS in charge of the TFS project. As a result, many of the same technical problems and ALL (plus some) of the workflow and usability problems have re-surfaced in Team Foundation Server.

It is also true that TFS is almost unusable because Microsoft doesn't dogfood this product (the irony of this reference is that Microsoft is cited in the first line). Internally they use something called "Source Depot", which sources tell me is actually a custom build of Perforce.

Is it all bad?
No. They did fix a couple of things. Your source control database will no longer randomly corrupt, and shared source editing is fairly reliable (although the merge tool is of very low usefulness). Checkin policies are a nice addition, tho hardly the earth shattering feature Microsoft has made them out to be. Changeset numbering is quite convenient. Shelvesets are also a nice feature - basically a mini-branch.

Show me the TFS vs. Subversion Comparison Grid
You asked for it.

Feature	TFS	Subversion
Binary file support	Yes	Yes
Revision History	Yes	Yes
Checkin rollback	Yes	Yes
Source Branching	Yes	Yes
Source Merging	Poor	Yes
Pluggable Merge Tools	No	Yes
IDE Client	Yes	Yes
Standalone Client	No	Yes*
Command Line Client	Poor	Yes
Checkin Policies	Yes	Thru custom dev
Bug/work item tracking itegration	Yes +	Yes ++
Multiple Workspaces	Yes	Yes
Portable Workspaces	No	Yes
Robust code recovery of local workspaces	No	Yes
Database storage	Yes	Yes**
Filesystem storage	No	Yes**
Mixed development environment support	No ***	Yes
Distributed/Public Network Support	No	Yes (on Apache)
Offline/Disconnected Support	No	Yes
Server Cost	$$$	None
Seat Cost	$$$	None

Notes:

* With (usually free) third party tools

** Subversion supports Berkely DB storage or filesystem storage - filesystem is usually recommended

*** TFS requires a Visual Studio project/solution for many basic operations. Sometimes you can fool it

+ TFS works out of the box with it's internal bug/work item system (crummy spreadsheet backed). Third party integrations coming to market slowly

++ Many, if not most, major bug tracking and project management systems already have Subversion integrations in place

Cards vs. Tools

Well, that startup collapsed. Under-funded. I had a few things to sort out in the mean time, hence the long gap. As I turns out, I got a sweet gig as an Architect for a major Internet site (who shall remain nameless). They do scrum over here, but quite a different variant than I have been doing.

The biggest difference is the use of cards/sticky notes for story management instead of a tool. I have to say, I don't like it. The biggest issue with cards is that there is a complete loss of historical data. Once the card goes into the completed stack or is torn up all knowledge goes with it. This includes sprint in which it was completed, original story points, issues, whether is was later unfolded, actual effort expended. There is only a velocity tracking for the last two sprints, and it is somewhat suspect.

I've also noticed that our backlog - perhaps subconsciously - has been limited by the size of our board and the number of sticky pads that will fit. It is actually impossible to retain even two months of data (forward or back), much less six to 12 months of data. Ouch.

While the tactilness of cards is nice during the sprint planning game, the loss of historical data far outweighs this. Modern Agile project management tools allow for drag and drop, so you can get this interactivity by using a laptop and a projector.