Reason to choose TFS over Svn/Jenkins/Jira

Question

I'm aware that there are a lot of questions on SO with similar content, but I can assure you that I have read the most of them completely with answers and comments.

My situation is slightly different in means that our company is mostly Java-oriented and thus the standard ALM tool set is already set up:

• SVN for Source Control
• Jira for task/issue tracking
• Jenkins for continuous integration

Now, I run a team of .NET developers and we need to set up something similar for our dev process and the discussion is whether to go separately with TFS or to reuse the existing infrastructure and plug in the .NET projects there as well.

I realize that the biggest pro-TFS argument is good integration with VS, but with our current setup I am wondering if there are some good arguments for not using TFS at all.

Answer 1

As someone who is using both SVN and TFS for .NET developmnet, here are the biggest reasons to choose SVN over TFS in my opinion:

1. TFS licenses are expensive. SVN ranges from cheap to free. You can install VisualSVN server with free standard license and use it commercially (http://www.visualsvn.com/server/licensing/) or pay for the enterprise version for under $1000.
2. One thing I've had happen several times in TFS is what I'd call the lost update. I've checked in a change, it doesn't make it to the rest of the team for some reason unknown to me. This seems to happen at least once every couple months or so. I've yet to have this happen in SVN.
3. TFS seems to get unnecessarily complicated if you choose to operate in a disconnected way. For some reason if you operate offline, it goes ahead and checks out config files for no apparent reason. SVN is disconnected, so it doesn't care. It's always offline.
4. Choice of integration level with Visual Studio - If I want to go to Windows Explorer to check in my changes or get latest, I can, with something like TortoiseSVN. If I want to integrate with Visual Studio, I can use something like AnkhSVN (my personal favorite). Granted, the TFS PowerTools have made this argument lest potent, as they now have Shell integration there as well, but I still like TortoiseSVN better.

Bottom line, I've found SVN to be cheaper to operate, more stable, and definitely more mature.

Answer 2

Microsoft Visual Studio Team System (VSTS) is a complete development environment for mostly Windows oriented development. TFS is at the heart of the system and plays a key role getting complete tracebility from requirement to final system test.

So one of the most important reasons to use TFS as Version Control System is because it play this central role in VSTS, allows this traceability and simply does the job. You might not want to call any of the VSTS components best of breed individually, but together they provide a seamless integrated CI development environment out of the box with a greater total than the sum of components.