TFS vs SVN

Question

I am going to run a project (.NET) and have to decide between TFS and SVN.

I'm more used to SVN (with the turtle client), CVS, and VSS. Does TFS have all the features available in SVN

Have you migrated from SVN to TFS and found it worth it?
It also looks like we need Visual Studio if we need to work with TFS.

[change]
Money is not counted, because we already have licenses for TFS. And I'm more interested in the Source Control features for TFS vs SVN, of course, a list of other features is welcome.

Answer 1

Well, for me, obviously, the choice of TFS:

• The integration of SVN in Visual Studio is at least incomplete (many functions are not available from the IDE) and a little buggy (of course, AnkhSVN), while TFS alone is perfect (which makes sense ...). I have corrupted the entire workspace several times, using SVN (within one month), never using TFS (aprox 2 years)

• Although the Source-Control-related features of both systems are probably quite equivalent, they are accessible directly from the IDE using TFS, while you must rely on TortoiseSVN or other external tools if you use SVN. Almost all TFS tasks are available in a few clicks on the Solution Explorer tab.

• Merging is much easier with TFS, even for complex merging (for example, SVN will add <<<<<<<<<<<<<<<<lt; <and → → → →> to your .csproj files , so you will have to manually them edit to reopen them from VS.)

Although I think these reasons are more than enough to prefer TFS over SVN, I will add that:

• TFS is more than just a source code management tool (think about work items, a project portal, etc.)

  I used it in a medium-sized project (12 encoders, 3 testers, 3 business analytics) in the past, and we were able to successfully centralize all the tasks in TFS (error reports, project documentation, build process, etc.)

  I'm not saying that you cannot do the same with SVN and other third-party tools, but it is certainly nice to have everything that is well integrated into one product.

---

To be fair, here are two obvious disadvantages of TFS:

• It's price

• Installing TFS is quite a pain, and installing SVN is a few minutes.

  Installing TFS 2008 on top of SqlServer 2008 is quite complicated, you cannot install TFS on PDC, etc. For me, this is definitely the worst installation experience I've ever had with a Microsoft product.

  In this case, as soon as installed, TFS is very easy to use (especially for encoders who are not familiar with version control systems)

---

In my current project, I started with SVN and quickly switched to TFS. I'm happy I did.

The main reason I decided to switch is apparently the general behavior with the SVN error (I used VisualSVN as the server and AnkhSVN as the client). At least once a week, I find that I spend hours on critical AnkhSVN error messages.

To date, I have not found a single reason to regret switching to TFS.

Answer 2

" Cannot be compared between TFS and SVN "

SVN : source code version control system
TFS : This is a complete software development management system that includes version control, release management, tracking requirements, publishing documents and other things.

Both have nice features using the IDE integration add-ons (e.g. AnkhSVN, Collabnet add-in) available for VS2005, so this should not be considered.

Criteria for choosing :
- If you do not have a budget project, select SVN
- If you are looking for a version control system, select SVN ; if you are looking for complete development management, select TFS
- If you have the patience to manipulate various integration tools (CruiseControl.Net, NUnit, NCover, FIT) to achieve an appropriate development environment, select SVN , or if you are looking for an implementation of everything for you then select TFS

Answer 3

Using TFS 18 months ago, I found that they were buggy, slow, annoying, very limited search criteria, and he had the feeling that the product jumped out of a team that was not interested, under paid, on the work of technicians who are forced to use Sharepoint and others MS technology because this is what marketing needs. Seriously, it was a dog, I'd rather use SourceSafe!

SVN, on the other hand, is a bit of a tech, IDE integration is a pain, and sometimes it can get confusing, but the user base is massive, and most problems can be solved with a quick SO request.

Did you consider Vault ? Works well and not too expensive.

Answer 4

I would recommend TFS only if you used the 2013 version and used the Git repository. I have encountered too many problems with previous versions to be considered stable.

• It is not possible to send multiple files to the diff tool at once. This is ridiculously useful when you want to view your changes before merging and are not available.
• Inconsistent availability of functionality. Some features are only available in the IDE, while other parts are only available in Windows Explorer, while others are only available from the command line.
• Adding files to a version control is not available from the IDE and is only available from Windows Explorer integration.
• Access to shelf sets is available only in the IDE and is not available through integration with Windows Explorer.
• Lack of a single unified installer. Installing TFS is not enough; you also need to install command tools and tools to provide basic functionality.
• The functionality of the shelf set does not merge. What could be a cool way to create private branches, in essence, ensures that your code is out of date and will stop working.
• You must manually unlock the text files before editing them if you need an editor other than Visual Studio.
• Sometimes Visual Studio forgets to unlock the files that it manages, and throws an error.
• Validation and deferred user interfaces contain accessible files for fixing what has already been added to TFS, and not what is actually present in the file system. This makes it easy to skip files. (Actually, this is a problem with the way Visual Studio handles project files, but this in itself is another spraying).
• There is no need to use Microsoft tools to edit your source due to the above problems.
• TFS configuration is done with your source. This means that if you change your TFS server, the configuration for your entire history is now incorrect. There is a default configuration that you can use that overrides this behavior, but this is not obvious.
• There is no support for ignoring filters on anything other than the basic level.
• Inability to process paths longer than 249 characters.
• Files that have been unlocked but not edited are displayed as modified, although they have not yet been. Differentiation between modified and unlocked will make it much easier for differences or even better eliminates the entire broken unlock system.
• The Windows Explorer icon overlay does not explicitly indicate whether the file has been edited. The entire file in TFS has a green corner, and modified files add a pencil to the bottom of the icon. Going to the red corner for a change would be much easier to see or use the system of turtles icons.
• Older versions of Visual Studio have problems integrating with newer versions of TFS. This means that now we have the IDE version dependent on the control source.
• Includes default custom solution files when they are not needed. Of course, I admit that this may be a matter of preference.
• Poor caching allows you to inaccurately reflect the differences between the local copy and the server. It is very unpleasant to get the latest and find that you actually do not have the latest.

Answer 5

It has been 1.5 years now when I use SVN for various projects. Settings I have used so far:

• AnkhSVN client for Visual Studio. It goes well with the Source Control provider from version 2.
• CollabNet Subversion servers for Windows or Apache 2.2 with SSL + SVN support via DAV on Linux.

I had no problems with any of these settings, and I definitely recommend using SVN as it is free and easy to use. Also, many project / bug tracking packages integrate with SVN (e.g. trac ).

Answer 6

I would choose SVN. I used to work with SVN from a developer perspective, and now I work with TFS, and let me tell you that TFS is painful. While TFS is fully functional and more than just version control, its version control is messy at best. Merging is terrible, and many of us now turn to manual merge or merge tools because we cannot rely on TFS. Files disappear, sometimes they are not downloaded to the local system, and there are simply oddities in its behavior that make you want to hit your head on the table.

At the same time, if you want TFS in all its glory, they are ready to work with their pain points, this is a great tool for setting up automatic builds and releases.

Answer 7

Read this article before deciding: TFS vs Subversion Comparison for Open Source Projects

Answer 8

I used both options - but in fact I switched my main projects from TFS to SVN. I believe that autonomous and anonymous access is very valuable in my projects.

In general, I think they are comparable. I would just choose the one that you know best and you are happy to support. I do not find specific functions in one dramatically larger number of functions in another system.

Answer 9

If you are familiar with svn, I will stick with it. Tfs is not free and not simple. This is much more than just source control. If you are a .net store like us, and you decide which product to use for the entire dev cycle, it is a rival, but it overflows for easy source control.

Answer 10

I would say that TFS is more than just source control. If you can afford it, I definitely recommend using it. When you, for example, start using Team Builds or use things like Work Elements, you will see that TFS can really manage your entire development life cycle, providing a rich environment in which reports, ease of use, flexible VS integration and reliable source control is all included in one.

This requires some server-side hardware. I do not think that it is slow, but it works fine through a VPN and supports battery life.

The main con is the installation process (on the server side), which is tedious, inflexible and in my opinion (I come from the area in which application packaging and deployment are very important) is a bad example of how SQL Server, Reporting Services, Sharepoint and web services can be installed.

Answer 11

TFS can import from SVN, but SVN cannot import from TFS. Therefore, if you did not find a good reason, use SVN, since it is easier to change your mind later.

One of the best things about SVN is that every source control system that I know can import from it, so choosing SVN gives us a very low risk.

Answer 12

In my experience, SVN is generally much faster and painless. I used it with XCOPY deployment scripts that let you work and deploy much faster compared to TFS.

Answer 13

I have no experience with TFS, but IDE integration is what you should think about. TFS obviously integrates very well with Visual Studio. AnkhSVN, the only useful free plugin for VS, is often problematic even in new versions. However, I have not tried VisualSVN.

Answer 14

Please note that TFS 2010 can also be installed on Windows Vista / 7 client OS and that it supports express, three clicks, installation.

Answer 15

Pros:

• Integration with Visual Studio . A real plus if you use full Microsoft technology. stack for development.
• Automated assemblies (although achievable with other products) are really beautifully made. Continuous integration and built-in registration builds are fantastic IMO.

Minuses:

• Windows Workflow Foundation . For some reason, the Windows Workflow Foundation was chosen as the method for configuring many aspects of TFS. In short, you need a Windows Workflow book to understand it, and I just don't have the time. IMO very disappointing.
• Project management . The concept of work items is quite simple, I think, but there are a lot of oddities that just leave me confused. It's just too complicated IMO. Based on the background of Trac + SVN, I prefer Trac here. Again, only my opinion.

Answer 16

If you do not understand what these tools are capable of, their limitations will mean that you have a tool that does not work as you wish. Understand your requirements and read product guides a bit - enough information to determine suitability.

While I completely agree with SVN supporters, since this is a great tool (I used it many times at the university), I found that TFS is generally more cooperative in OOTB situations when you use the SP1 Version with Studio 2010.

In addition, there are some nice plugins that make TFS more enjoyable for those of us who are used to and usually prefer a solution like SVN, and many of them have excellent support:

TeamReview for code review is one example: http://teamreview.codeplex.com/ MS Pathways for multi-platform use of TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

This SO question is a great resource for TFS add-ons: What add-ons / utilities are available for TFS?

A word to the wise, as mentioned above, TFS can be a pain to be fixed, so caution should be exercised. Following the route below, I ran into minimal problems:

Studio 2008 → Patch → Studio 2010 → Patch → .NET → SQL Server 2008RD / 2012 → Patch → TFS → Patch