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

I've worked with both sides of the fence. I was originally forced to use SourceSafe. I hated it with a passion. When I was in a position to steer IT policy I tried a few different options and went the SVN and Trac route. It was not without its learning curve as well but the results were great.

I then started working at a pretty big place which uses SourceSafe and RedMine. I missed SVN majorly, but I liked Redmine.

We more recently moved everything to TFS and Jira. Sometimes I think big companies do things just because they like spending money. Even though a lot of the data integrity issues might be sorted on the back-end, TFS is almost as painful as SourceSafe to actually work with.

Of those options, SVN and Jira would be the preferred combination. SourceSafe would be at the bottom of the list, very closely followed by TFS.

Answer 2

Good question(s). I've never used TFS but all this certainly is possible with a number of tools. The biggest hurdle is the culture and mindset of the company and developers.

I am pro SVN. (But TFS would work I am sure)

I'd suggest very light intrusion on daily tasks.

Having sandboxes or promotion rules from one branch to another in SVN is one way to do code analysis without holding up the commit process.

So, to address each of your points: SVN handles source control and is ancillary/included in change management and Release management

Change management/Workflow is basically defined by the project team and can be helped with simple tools or just enforced by policy.

Release management is also policy based and uses the existing framework/tools (SVN)

Most any of the popular defect/issue tracking systems will handle the Incident and Document management - think wiki with trac or fogbugz (along with SVN for doc mgmt)

FXCop and all the other tools can be part of a build for code analysis

Testing framework is more policy based than tool driven - you have to make it a priority if that is what you want.

Your reporting notion is vague, but I think you have more than enough tools in any scenario to satisfy this

I am not sure what you really need as far as integration with 2008. In any case this not much can be as as tightly coupled as TFS, but I don't see that as a problem.

(I think you answered your own question.) This may end up being a religious war between MS and anti-MS sides.

In the three places I was at where I was in charge of recommending and implementing a solution, we voted with our wallets - against MS. I am sure TFS is capable, but the competition is quite up to the task and I think those tools translate well for other jobs.

As for tools to consider - I think searching Stack overflow for nant, msbuild, cruisecontrol, etc will give you more content than you can shake a stick at...

Answer 3

If the target developers are Microsoft-centric and the customer wants enforcable process, then staying with the TFS is a good call. Implementation costs have to take into account the learning curve, any lost productivity and existing infrastructure. If this is a big shop, and it sounds like it is, you'll also need an "IT" team's buy-in, which may be hard to get with a whole new technology stack.

Having said that, here are some other options:

You might want to take a look at Subversion + Atlassian's Jira (issue tracking), Confluence (wiki), Bamboo (CI), Clover (code coverage), Fisheye (repository "insight")

These are commercial tools, but are also already integrated and integrate well with Subversion.

The Rational toolset, which IBM now sells and develops, is robust, reliable and is very process-oriented. Probably more expensive than TFS, though. I have not used this recently, but in past engagements it performed well for those shops.

And finally, there's Computer Associate's Software Change Manager which has the most obnoxious process enforcement of any tool I've ever had the misfortune to be forced to use. But if anal-retentive, obsessive/compulsive mandatory process is what you want, this is the tool for you.

Answer 4

VisualSVN provides really good integration between SVN and VS. we migrated from TFS to SVN. back then(about 2 years ago i think...) what we felt was that TFS was bloated and slower(much slower compared to svn). But i am sure by now it must have improved.

One main difference between the two routes is that TFS can be setup easily when compared to a 'svn stack'. you would have to install different tools and applications and get them to work together. it would take some time. but after wards it will work with out complaining.

Answer 5

Though question, I think both routes have their merits. I really like the usability of basic & daily operations that TFS provides through it's Visual Studio integration. GUI'wise if you compare it to TortoiseSVN it really looses feature wise. TFS does have a command line utility that covers most functionality missing in the GUI. Beyond source control I think TFS provides far stronger cohesion when it comes to setting check-in/commit policies, associating it with work items and such. I like the web interface in particular that TFS provides (although do look into it's licensing model before getting overly enthusiastic) Merge conflict handling is rather poor in VS2008, something they will be improving in VS2010. TFS is somewhat a jack of all trades, perhaps mastering non. However also TFS allows hybrid solutions when it comes to continuous integration, various tools from what you call "Subversion stack" can be used in combination with TFS also.

Answer 6

I think the following stack is superior to TFS:

• VisualSVN Server - source control
• Jenkins - automated build
• Redmine - issue tracking

Each one of these tools serve a specific purpose and stand on their own merit. They work well together but can be replaced individually when something better comes along.