CODEWITHSUNDEEP
svnversion-controltfscontinuous-integrationjenkins
ljubomir
ljubomir

Reputation: 1525

Reason to choose TFS over Svn/Jenkins/Jira

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:

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.

Upvotes: 10

Views: 5920

Answers (3)

autocro
autocro

Reputation: 11

If your team uses visual studio you basically get VS Team Services for free, which is include a lot of TFS functionalities for free for small teams. On top of that you get free credits on azure every month and are set on the infrastructure side to start. Resuming, you don't need a TFS license if you already have a visual studio subscription to do most of the things involved in developing an application.

Upvotes: 1

kroonwijk
kroonwijk

Reputation: 8400

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.

Visual Studio Team System 2008

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.

Upvotes: 4

Nathanael Schulte
Nathanael Schulte

Reputation: 650

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.

Upvotes: 9

Related Questions