An overview of the Team Foundation Version Control (TFVC) integration with VSTS. Learn how to incorporate TFVC into your DevOps process.
- Team Foundation Version Control or TFVC is a centralized version control system in VSTS. Team members only have one version of the file on their developer machines at one time. The historical data and all other data is maintained on the server. The branches are path-based and are created on the server. So, branches tend to be a little bit heavy-weight. They're not something that's disposable such as in the Git system, and they're not highly used. We try to keep our branches to a minimum when we're using TFVC.
Okay, so now, let's go take a look at Team Foundation Version Control in Visual Studio and TFS. I'm here in Visual Studio, and you'll notice the screen looks a little bit different than it did when we were in Git. Again, on the right side, I'm in my team explorer. And, we want to look at this option right here called the Source Control Explorer. That's the interface into the version control system for Team Foundation server. So, if I click on that, it's going to open up this Source Control Explorer window, which is the whole window you see in the middle of your screen.
And, basically allows us to navigate through the project and the files. So, you can see in the center of my screen, I have all the different files that are available to me and I also have my project right here that I'm working with. This is my MercuryHealthTFVC project. So, next we're going to actually right-click on this MercuryHealth, and we're going to show you some of the options you can do in the version control system. One of the things you can do is get latest. You can check files out for edit.
You can delete, rename, and even move files around in the version control stystem. Again, all of this is taking place on a server, not on your local machine. You have the ability to roll back if in fact you make a mistake or somebody checks in something that's broken. You can roll back to a prior version. You can check in your pending changes. A little bit different terminology than Git where Git does a commit. In TFEC, we actually do a check in. We can actually shelve our pending changes. That basically means, we're going to put them up in the server, but not integrate them into the mainlined source control.
At some later time, we can actually pull it back down and continue working on those. A great use of shelving, as it's called, is for us to be able to push our work up into the server so that next day, we can come back in and we can work on it without having fear of losing it because it's only on our local machine. It's a great way to manage our changes. Again, another good reason for shelving is if someone's going on vacation, for example. They can shelve their changes prior to leaving, and when they come back they can actually bring them down, or they can assign them to another team member and they can bring down those changes and complete the work that they were doing.
We can view the history of a particular project file or branch. We can compare files. We can add items to the folder. This is a way for us to add items into the version control system. We can branch and merge. So, again, branching and merging is a lot more heavyweight, so we don't actually want to do a lot of branching and merging if possible. If you're going to use branching and merging in TFVC, make sure you're merging often in small amounts. Don't do a whole lot of work, and then at the end of the day, you decide you want to merge all your changes.
Or wait week and merge your changes. It's going to cause a lot of problems for you to do that. There could be a lot of errors that come up, and you're not going to be able to merge them very well. So, again, merge early and often if you choose to use the branching and merging functionality in TFVC. We can actually go and find different files in our system. We can find by a version control label, by a change set, or even find in shelve sets. And then the advanced option. I can actually go back to a specific version.
So, maybe I want to go two versions back. I can go up here, and I can click on that and get to a specific version out of version control system. I can do that by change set or by label. I can actually apply a label or lock files. So, if we lock the files, basically we're the only ones who have access to those files. There are a couple locks in TFVC. One of them is a check in lock, one of them is a check out lock. What that means is that users can check the files out and work on them, but they can't actually check them back in.
And the other lock type is one where the user cannot check anything or check in anything. So, it's completely locked down. Lastly, we can cloak. Cloaking is, think of it as a way to hide files from being pulled down from the version control system. They're there, but we cloak them. Think of it as a cloak of invisibility. They're there, but we don't actually bring them down into our system. Let's go back to the MercuryHealth project, and let's go to the center screen here, and you can notice where we have our local path up top here.
Our local path basically tells us where are the files located on our system, on our local machine. And that's a workspace. And workspaces are set up between your local machine and the server that TFVC is using. So, that way then there's a communication link between the two. If, for any reason, you can't communicate with that server, files cannot be checked in. Again, that's one of the other down sides of working with a centralized system like TFVC is we have the inability to really work offline as much as we'd like to.
You have to make changes locally and when we get back to the system and we can plug back in, we can then start to check our changes back into the system. I prefer to not work offline at all in TFVC. That's how we work in the Team Foundation Version Control system.
- What's DevOps?
- Version control Git
- Using TFVC
- Creating the continuous integration build in Git and TFVC
- Continuous delivery
- Creating and running a release management pipeline
- Continuous testing
- Implementing Application Insights
- Reading Application Insights data