I like Git over TFVC

I’ve been on a new contract and we are using TFVC here. It’s a decent tool (used to be THE tool and was much better then SourceSafe before that) for version control (you’re doing version control, right??!!), but I’ve found myself saying “Git is so much better” out loud. I do really miss Git, but I need to be careful in presenting change (I don’t want to cause angst or feelings that things can’t be changed in the developers current company. I want to provide a view of what I and others at Omnitech have experienced as good and helpful to the development process).

The following are some reasons I’ve thought of, with help from my co-workers on MS Teams, on why a team might go through the disruption of changing version control, training, learning, questions and updating builds. Will it really help and increase our productivity and developer happiness over the long run?

I was a part of a different company that went through a TFVC to Git transitions a few years back. It took me a few months to get comfortable, so I’m aware of the learning curve. We definitely relied on our Git guru to fix our branch messes, but after a few weeks we all adapted well.

A few things I like about Git

Some of this is in contrast to TFVC.

1. Pull Request work flow and UI with Azure DevOps
   1. TFS 2018+ and Azure DevOps has a very nice web interface
   2. policies on PRs that require tests to pass, approvals, etc.
   3. TFVC - code reviews disappear after “looks good”, you don’t see the updates
2. Moving files and folders is much easier
3. Local branching workflow
   1. Easier to collaborate
   2. Light weight
   3. Trunk based is easier
   4. Local commits provide an easy way to back out of local changes
4. Switching branches is really fast
5. Less frustrations once you move to it
   1. This is subjective, but I’ve pulled my hair less when working with Git (after I got the hang of git)
6. What if TFS goes down or is unavailable?
7. Merge more quickly
8. Work with others more easily (point them to a branch)
9. The Azure DevOps Team uses it, moved from TFVC “increased agility”
10. You can use the GUI or the command line (and don’t have to be only in Visual Studio)

Overall, I feel more productive with Git (after the initial learning curve) and that I’m not fighting with it the way I do with TFVC. I feel that the pain to switch (and lost time) will be more then made up with by the PR improvements, culture improvement possibilities, easier to find experienced Git Devs and branching.

TFVC frustrations (venting)

1. Get specific version to override (it didn’t get latest and I’m missing files?? This gets me every once in awhile)
2. adds a read-only file flag, I’ve had to manually remove this
3. when working outside of VS (think VS Code or Notepad++) have to find in Source Control explorer, then right click check out for edit.
4. Checks out files I didn’t change on build (Service Fabric solutions)
5. We get code review comments that say “nothing changed”. To avoid this you have to go through each file and compare with latest. (Git compares the file and doesn’t just remember that you checked it out at some point).
6. I spend a lot of time in the Source Control Explorer and clicking through folders to find my file.
7. I have to undo changes when I add something then delete it (before checking in)
8. Merging
   1. When merging a suspended work or shelveset “TF203100: You cannot un-shelve a change to $/[some file] because a deletion of this item is already pending in your workspace. You must either undo the deletion or exclude this item when you un-shelve the shelveset.”
   2. When I need to merge to QA or RC (we can’t all live in the TBD world, though we’re trying to get there ) I have to suspend work, merge, check in, suspend and delete that after the Gated build finishes. It’s hard to do other work in the middle.
   3. The merge window from branch to branch sometimes takes 30+ seconds to load up when choosing selected Changesets.
   4. The merged changesets don’t always disappear from the merge window after being merged (sometimes due to a necessary manual change while merging).
   5. You can’t merge multiple changesets that aren’t next to each other (someone else checked in, before your second changeset and now you want to squash your 2+ changesets together)
9. Resuming suspended work timed out on me today… stuck in the loading state in VS. I’m going to have to kill VS.
   1. 
10. Open the solution before connecting to the VPN (or TFS is down), then I get prompted to Go Online.
11. It’s not easy to see changes or got back for long lived feature work.
    1. I almost lost a day of work when I was switching between shelveset with the Suspend and Resume work (too much context switching), but my files disappeared at one point. Thankfully, I was running a local git repo and was able to revert the commit where it disappeared. It had occurred when I got latest.
12. It promotes long lived, large change-sets as the normal process.
    1. Trying avoid the difficulties of trying to squash changesets together.
13. Each branch requires a new folder structure and full copy of the code.
14. Trying to move files, then to suspend my work to create a shelveset isn’t always easy
    1. 
15. Moving files to different folders is not fun!
    1. I like to re-organize often, but in TFVC it becomes a headache. So people don’t re-organize and things stay in a mess or become worse.
16. Branches are complete copies and you have to remember which folder on disk you are on.
    1. Have you ever started coding and realized you’re in the wrong place?
17. Trying to merge 2 changesets to the next branch that are not next to each other
    1. Why doesn’t it just show a merge conflict window and let me resolve the conflicts? If I want 1 changeset, I have to undo the file, try again and see if there is another file in conflict.
    2. 
18. TFS OnPremise goes down, re-connecting isn’t easy
    1. If you’re doing local Git:
       1. move the .git folder into a different directory
       2. Connect to TFS
       3. Right click solution, then go online
          1. Wait for the dialog to populate “offline changes made to this solution”
          2. choose all the files you need to be added or marked as edited, since you lost connection
       4. then move the .git folder back in. Don’t do that before you make the solution online!
       5. remember to click no on the dialog that asks if you want to switch source control provider.
    2. Then It feels like a fight to get it connected.
19. What does this mean in the Azure DevOps build??? ##[error]Exit code 1 returned from process: file name ’tf’, arguments ‘vc unshelve Gated_2020-02-13_01.59.46.2397;klogan /loginType:OAuth /login:.,*** /noprompt’.
    1. look for code outside of the source folder and do not include it. Mine was mapped to a Source folder and I was trying to include from a different folder in this check-in.
20. vspssc??
21. 
22. “The VPN disconnected so TFVC completely loses it and has to go offline. I make some changes and when I try to save it tells me that the files is readonly. So I need to click all the buttons that make TFVC decide it’s time to “Go Online” which apparently also tells it that I need a bunch of .vspscc files littered all over my Pending Changes. The .tfignore file specifically says to ignore those but does it listen, heck no!” ~Brian
23. Someone locked a file, now they aren’t a part of the company and I can’t delete the dll that doesn’t need to be in source control.
24. “Unable to perform operation on $/…/x.dll. The item is locked in workspace REM-LT-LMNOP_14;JJ Bean.”
25. Azure DevOps TFVC does not support YAML pipelines https://learn.microsoft.com/en-us/training/modules/implement-pipeline-strategy/8-explore-source-control-types-supported-by-azure-pipelines

Moving in files from a different source

I’ve been working with others in a private Git Repo (since the company isn’t ready for Git, but this is a couple months of work, so I decided to live in Git as long as possible. In Azure DevOps, I have my own board, pull request and build. It’s very nice!). Now it’s time to move it into TFVC. The first time it took me about an hour to get the build started :-).

First, I tried StackOverflow . It didn’t work to compare and use a filter, because the Reconcile button is grayed out :-(.

Here’s the filter I used in the VS compare window:

!*.dll; !$tf\; !.vs; !bin\; !.git\; !v16\; !TestResults\

Here’s what worked

1. Copy the folder (exclude the .git folder, maybe delete all the bin dirs first)
2. Right click folder in Source Control Explorer and checkout
3. Keep this folder selected in Source Control Explorer and click the add items icon at the top.
   1. Make sure the packages folder (NuGet) and other things you don’t want (dlls, etc) do not get added.
4. Renamed and deleted files need to get removed manually :-(
   1. Find each one in Source Control Explorer and right-click undo checkout then right-click delete.
5. Try to check in again

back to step 4 after you see this error.

When adding new projects that were in Git to TFVC, TVFC needs to add

  <PropertyGroup Label="Globals">
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
  </PropertyGroup>

to the .csproj for it to be bound.

Local version helps?

Months after I wrote this, A co-worker pointed out changing the location to local from server.

“A caveat to the local workspace is that it can make some TFS operations take longer since it creates some extra local data on your machine to make it so it can catch changes to the local workspace. Also, shelvesets become more important because a local workspace won’t regularly sync your workspace to the server and save your changes with the server.” ~Ryan

I’ll try it out and add some more thoughts someday (if I remember :-)).

A few things I like about TFVC

1. It is way better then SourceSafe was.
2. We definitely needed it when it was introduced with TFS 10 years ago
3. The Suspended work is a nice feature.
4. Code Reviews are a good feature (but Git Pull Requests and UI is much better)

Donovan Brown’s insights

Donovan Brown does a great job presenting DevOps and happens to work at Microsoft. The Azure DevOps tools are really good and the team there has made the transitions themselves. In August 2018, Donovan tweeted .

This points out that you don’t have to move if you’re happy with TFVC and don’t want to make a change. However, there are many comments that point out the benefits of Git. One at the top from @t3rse (how I’ve had the pleasure working with and am proud to call a friend) said “I disagree. Being forced to think like a git improves engineering skill, not just for Microsoft but for literally anything. My guess is there are zero jobs that don’t require a deep understanding of git outside the halls of MSFT.”

Later on, Donovan responds to this and others “I would agree more with your statement if we did not offer both. But we do. You want Git fine. Not ready for Git fine. How is giving people choice a bad thing? You choose what is best for you.”

@TfsBuck is another good source for a Microsoft Azure DevOps engineer.

Donovan did an interview/conversation about Git in May 11, 2018 at Build .

Notes from their chat

• the 2017 StackOverflow survey said 87.2% use git in some way
• Branching is cheap
  • leads to developers merging more quickly
  • Avoid “Merge Bomb”
• Protect my peers?
  • Feature flags
• Pull Requests
  • Protect master
  • Tests
  • Approval required
• VSTS team (now Azure DevOps) uses it, moved from TFVC “increased agility”
• Learning Cure?
  • Use a GUI
  • Lot’s of resources are out there

How to transition?

Now that you’re convinced you want to use Git (you are convinced aren’t you?) and that it’s good for your team, how do you move towards it?

I got to help our company transition to Git! I’ve written up a more in-depth plan in 2020.

In my experience…

Identify 1 or 2 people that are or will be Git experts, learn yourself

You need 1 or 2 people that are Git experts ready to help others when they make a mess of their branch. Identify that person(s). Do you need to dig in and learn before introducing to your team? The rest need to know how to do the basic steps either in Visual Studio or GitHub Client or in the command line (see my article Some Git Help for 5 easy command line steps to getting latest into your branches).

You can start using Git, while still using TFVC. It’s a great way to practice and to get used to creating small commmits. It also gives you a way to look through your personal history and revert/go back if you decide to undo in the future. It also gives you a back up in case you loose something with suspending and resuming (like I did last week). Visual Studio gets a little confused, but I’ve had good success using the Github client. Remember to still create some shelve-sets so you get a code backup on the TFS server and to make sure you have all the files marked as “add”.

All you have to do is go to the root directory in the command line and type git init, git add ., git commit -m "initial". You’ll probably want a .gitignore file first.

Share your excitement, talk to the team, build consensus

You need to be able to be the champion for change. This includes sharing stories (like mine and others), videos, articles and showing what you’ve learned. Have some lunch and learns, show off how to use git and a Pull Request in GitHub or Azure DevOps, start a book club ( the Pro Git book is free!! ). This may take some time.

Emphasize small local git commits and good Git practices. Talk about the way you want to do at your company.

Do you have a multiple branching code for change isolation? Talk about how to do that now in Git. Maybe this is even an opportunity to start the transition to Trunk Based Development , but don’t take on too much at once. The move to Git will be disruptive enough.

Now that people are aware of it, it’s time to see if you’re team is ready. Talk to your team and your manager about how to get the priority to introduce this change and possible interruptions.

Come up with a plan

I’m thinking about Azure DevOps pipelines as I write this.

1. Will you try it with a pilot project or go all out across the whole company?
2. Will you go with one big repository or several small ones?
   1. Google does one giant repo
   2. Think about how your teams are organized.
3. Update builds and release
   1. get source tasks
   2. Do you have custom powershell tasks for versioning, etc that check things into source?
4. Migrating the source code from TFVC to Git.
   1. What tools are available?
      1. Azure DevOps has a built in tool
   2. History, do you need it all?
      1. “You can migrate up to 180 days of history starting from the most recent change-set. A link to the TFVC repository is added in the commit message of the 1st change-set that is migrated to Git. This makes it easy to find older history when needed.” ~ Azure DevOps link
5. What policies do you want to add to your Pull Request to improve quality?
   1. You have a GCI build already, right??
   2. 1 or more approvers? Someone from a specific group?
   3. Can you approve your own changes?
6. Plan for time for the “expert” to help with others changes.
7. Plan for a retrospective in a few weeks
8. Share the wins and challenges with other teams and help them make the transition

More Resources

• my article Some Git Help for more help working with Git and links.
• the Pro Git book is free
• A longer more in depth article

• More like TFVC RC branch merge https://t.co/wraMTLP6hC

  — Kevin Logan (@alignedDev) March 15, 2019

• Interactive learn Git
• CodeSchool learn Git
• Try Github.io
• Docs
• update files outside of VS

What do you think?

Do you have an argument not to move from TFVC that I didn’t think of?

How’d your transition go?

Finish with a cheer

The title feels like a high school cheer chant. It reminds me of marching band, “I’ve got spirit how about you?” that we’d yell to the other schools.

Minions cheering seems to fit…

via GIPHY