Q: "What should I do in order to work with Team Foundation Version Control?"
A: TL'DR: Use the TFS command line client,
? But why use TFVC ?
Azure DevOps is confusingly several products. There is the cloud offering: DevOps Services, formerly known as Visual Studio Team Services, formerly, Visual Studio Online, formerly Team Foundation Service. There is also an On-Premise offering: Azure DevOps Server, formerly known as Team Foundation Server (now 2020, formerly 2019, 2017, 2015, 2013, 2012, 2010, 2018, 2005). They do share a common REST API, albeit the on-prem lags behind.
Aside from the delay in getting features into the on-prem variant, the questions of choosing on-prem or cloud have nothing to do with choosing TFVC vs Git. It likely depends more on cost, infrastructure and people resources, geographic and network constraints.
You can see most of the Product Announcements from the Program Manager here.
From TFS 2005 to 2012, the version control engine was TFVC, a centralized version control tool. Team Foundation Server 2013 added native support as a centralized Git remote host (similar to Github/Gitlab/BitBucket,but on-prem), albeit in separate team projects. TFS 2015 Update 1 (clumsily) allowed hosting both in the same team project.
But, let's get back to today. Since TFS 2015, Microsoft has put very little effort into improving the TFVC side of their offering. It would seem today, they have essentially abandoned it. Team Explorer Everywhere is no longer maintained. In 2016, they open-sourced it. Admittedly, in 2017 they did reintroduce it after a large outcry. The Eclipse client was last updated for Neon release (2016-06). The tfs-plugin for Jenkins has not had a significant release since Mar 2018. On 2020-11-06 (Nov 6, 2020), the Visual Studio Code plugin will be removed from the VS Code Marketplace; users will have to rely on the
tf command line.
The Program Manager's first post detailed TFS Usage within Microsoft. Those were last updated in 2013. A few years later, they are now boasting of having the world's largest Git repo and then acquired GitHub.
The basic question you should be asking is Choosing the right version control for your project? Do you want a Centralized model or a Distributed model of version control?
I have a lot (decades) of experience managing Centralized and Distributed version control systems. As MS documents, each have their strengths, weaknesses and trade-offs. But, why would you choose a centralized version control tool that is provided by a vendor that evidently no longer supports it?
PS: Most people visualize Centralized Version Control like this:
and Distributed Version Control like this:
But that is really just a "disconnected, centralized model". Git allows for very complex distributed workflows, such as show below. You do not get that flexibility using centralized tools. But it can also be a total nightmare to keep track of what's where.