It's a relatively simple version control system so it works great for an individual or small team (less than 10 people). But if you have a medium to large team, especially one with members distributed over a large geographic area, or one where individuals need to be able to work "offline" without access to a central server, Apache Subversion will likely not be the best choice.
Also, if you're maintaining an open-source project where outside people will be interacting with your code repository, git is probably a better choice because it's becoming the de-facto standard these days and what most developers are familiar with.
TeamCity is very quick and straightforward to get up and running. A new server and a handful of agents could be brought online in easily under an hour. The professional tier is completely free, full-featured, and offers a huge amount of growth potential. TeamCity does exceptionally well in a small-scale business or enterprise setting.
Distributed development - I've never worked in an environment where distributed development (developers widely scattered geographically) was a factor, but that's why git exists.
Merging - Merging of code from one branch to another can be painful, especially if it's not done frequently. (On the other hand, doing merges is one of the reasons I get a nice salary, so I can't complain too much!)
Acceptance - Let's face it, git is what "all the cool kids are using." If you've got a bunch of developers fresh out of school, they'll probably know git and not Subversion.
The customization is still fairly complex and is best managed by a dev support team. There is great flexibility, but with flexibility comes responsibility. It isn't always obvious to a developer how to make simple customizations.
Sometimes the process for dealing with errors in the process isn't obvious. Some paths to rerunning steps redo dependencies unnecessarily while other paths that don't are less obvious.
While there are interesting alternatives, such a GIT, Subversion has been a breath of fresh air compared to its predecessors like CVS or Microsoft Source Safe (now called Team Foundation Server). Its ease of use and high adoption rate is going to keep me using this product for years to come.
TeamCity runs really well, even when sharing a small instance with other applications. The user interface adequately conveys important information without being overly bloated, and it is snappy. There isn't any significant overhead to build agents or unit test runners that we have measured.
Git has become the new standard of version control, with its support for distributed design. As a tool to manage and control versions, Subversion does it well, but Git is the future.
TeamCity is a great on-premise Continuous Integration tool. Visual Studio Team Services (VSTS) is a hosted SAAS application in Microsoft's Cloud. VSTS is a Source Code Repository, Build and Release System, and Agile Project Management Platform - whereas TeamCity is a Build and Release System only. TeamCity's interface is easier to use than VSTS, and neither have a great deployment pipeline solution. But VSTS's natural integration with Microsoft products, Microsoft's Cloud, Integration with Azure Active Directory, and free, private, Source Code repository - offer additional features and capabilities not available with Team City alone.
TeamCity has greatly improved team efficiency by streamlining our production and pre-production pipelines. We moved to TeamCity after seeing other teams have more success with it than we had with other tools.
TeamCity has helped the reliability of our product by easily allowing us to integrate unit testing, as well as full integration testing. This was not possible with other tools given our corporate firewall.
TeamCity's ability to include Docker containers in the pipeline steps has been crucial in improving our efficiency and reliability.
