I work for one of the largest state government department in my state. They’ve been using TFVC since before I joined. I’m currently the TFS Administrator. We’re thinking of moving to the cloud, probably using Azure DevOps for project management and CI/CD, but GitHub for our source repository.
As the TFS administrator there are two bad habits that I struggle with which people do in this state department. In fairness to my colleagues, I believe they never received any training on proper source control, branching strategies, etc. The first is people have a bad tendency to do their own modifications to code, then check it into TFS, stomping on whatever else someone before them has checked in. For example, more often than I’d like, Person A will add a file and check it in. Then later Person B will add their own file or remove a file, then check everything in, ignoring the conflicts the Visual Studio (VS) raises. Now Person A’s file is gone (as far as TFVC is concerned) because it’s no longer in the VS project file. This happens repeatedly, so many times that it becomes almost a full time job, just getting the files correct so that both Person A and Person B can continue their work.
The second bad habit results from some managers wanting to get new apps generated as fast as possible. So, what happens is a team will create a base VS project. Then when they need to start a new project to satisfy some new need, they will create a new empty project in TFS, fetch the empty project down to a new folder on their machine, then go back to the base project where they will branch it into the new folder they created on their machine, and start working with it there. There is never any intention of merging these new projects back into the base project. So, new projects proliferate in this way. We’ve got several of those types of projects now. It’s my understanding that the managers who’ve encouraged their people to do this have done so with the erroneous thinking that if their people make a change to common code files in the base project, then it will automatically be migrated to all child projects that have been branched in this fashion. Of course, this doesn’t work as they expected. But they’re still getting a new functioning project, which they are happy with.
The first problem is one which I think any practitioner of TFVC or Git could fall into doing if they’re not careful. The second bad habit is something I think might only be possible to do with TFVC. I’m not entirely sure. I’ve been using Git for almost two years, but I’ve been working alone so haven’t any experience branching and merging with two or more people. Anyway, we desperately need to have training, generically speaking on proper branching and merging strategies and with Git in particular.
