Is the Subversion 'stack' a realistic alte

Question

I'm evaluating Microsoft Team Foundation Server for my customer, who currently uses Visual SourceSafe and nothing else. They have explicitly expressed a desire to implement a more rigid and process-driven environment as their application is in production and they have future releases to consider.

The particular areas I'm trying to cover are:

• Configuration management (e.g., source control)
• Change management (workflow and doco for change requests, tasks)
• Release management (builds and deployments)
• Incident and problem management (issues and bugs)
• Document management (similar to source control, but available via web)
• Code analysis constraints on check-ins
• A testing framework
• Reporting
• Visual Studio 2008 integration

TFS does all of these things quite well, but it's expensive and complex to maintain, and the inexpensive Workgroup edition doesn't scale. We don't get TFS as part of our MSDN subscription.

Those problems can be overcome, but before I tell my customer to go the TFS route, which in itself isn't a terrible thing, I wanted to evaluate the alternatives. I know Subversion is often suggested for its configuration management/source control, but what about the other areas? Would a combination of Subversion/NUnit/Wiki/CruiseControl/NAnt/something else satisfy all of these requirements? What tools do I need to include in my evaluation?

Or should I just bite the bullet and go with TFS since we're already invested in the Microsoft stack?

Answer 1

Our stack looks like:

Configuration management (e.g., source control)
SVN

Change management (workflow and doco for change requests, tasks)
Trac

Release management (builds and deployments)
Hudson

Incident and problem management (issues and bugs)
Trac

Document management (similar to source control, but available via web)
SVN (with Apache for web interface)

Code analysis constraints on check-ins
Coverity

A testing framework
Hudson (supports many various unit testing frameworks)

Reporting
StatSVN

Visual Studio 2008 integration
VisualSVN

Answer 2

I associate the "Subversion stack" with FOSS for some reason. Not that it can't be used for enterprise work, but in my experience, enterprise customers prefer the all-in-one solution.

Answer 3

As much as people hate consultants, you might consider talking to a firm that does commercial svn support. If TFS is as expensive as you say, this may save you some money with the benefit of starting you off with a good setup. There are risks involved with this of course.

Answer 4

Some very large projects are succesfully running on SVN or GIT.

I would be inclined to use different best of breed apps that talk to each other than a single monolithic creation like TFS. A lot of free and commercial bug trackers integrate with SVN as do test runners. It's also generally easier to create your own interfaces to something like SVN than to make an MS server app do something new.
And finally it's easier to migrate from something like SVN to the next great new thing than to get data out of a proprietry package like TFS.

Answer 5

Team Foundation Server also includes build management, TFS build management can be used for Continuous Integration as well as release builds etc.

I have used CruiseControl.NET with Subversion for build management and it worked. However TFS will give you more control and auditing etc. Consider if you wish to have that level of control over your programmer, or should you be trusting them more.

Also consider Vault or Fortress from SourceGear, as the are designed to be easy for people that are used to Visual SourceSafe, .e.g. they have pinning.

Answer 6

I would look into SVN,Trac,CruiseControl, and Nant... all free, open source, and extremely mature.

I have convinced my workplace on this stack, and I haven't looked back...