2

We have a large TFS repository which we would like to migrate to git.

We are considering using git-tfs for a while, in order for everything to continue working while we migrate.

We have large (or small, but rapidly changing) binary files scattered throughout the code, which have been checked-in to tfs throughout the history.

My worries about git-tfs I have not been able to find accessible answers for:

  1. What is the source of truth for git-tfs? Is it a git server, a tfs server, or some hybrid, or none of the above?

  2. If it is a git server, how would this affect workflow while knowing binary files exist?

  3. We thought of using lfs, but not sure how this wuold play with git-tfs.

I would love some light shed on this topic, as it would be quite pointless to migrate only to find out binary files make the new repo not usable

Gulzar
  • 121
  • 4
  • What is "lfs"? I guess you mean "LFS", but I don't expect you mean Linux From Scratch, which is the most relevant match I could find on the first page of DDG – l0b0 Jul 29 '19 at 06:11
  • 2
    @l0b0 Git LFS is the Large File System feature that allows storing binary references rather than the actual binary files themselves in the repo. This allows keeping the repo small with just text files and the differences over time in those files. – Sumo Jul 31 '19 at 16:12

2 Answers2

1

As of Azure DevOps Server 2019, migration from Team Foundation Version Control (TFVC) to Git is a simple import command. However, there are caveats to the migration due to how very different Git is in how it stores changes.

Microsoft has a great write-up for this migration and if you have the newer version of Azure DevOps Server or if you're in the cloud, you don't need git-tfs.

But, a few highlights:

  1. Git is distributed version control, which means that you have a full copy of the files and all historical changes simply by cloning the repository to your machine. You technically don't need a server, but if you have a team and collaborate, a server is needed to share changes with the team via appropriate Git workflows and branching.
  2. Git is really good at storing text files and will only ever store a single copy of a file with each commit storing a snapshot of the differences in that file over time. Binary files require storage of the full file for each commit that changes the file.
  3. When binary files need to be stored in a Git repo, it's best to use Git LFS (Large File System). This allows you to mark files as large/binary and Git will only track a reference to the file, not the actual file itself. This keeps the repository small and nimble.
  4. When you have an enormous repository (files/history) that is in the 2-4 GB range, you may need the Microsoft-contributed Virtual File System for Git, which Microsoft uses for its enormous 500 GB Windows code-base that developers all around the globe work from. Contributions from Microsoft and the rest of the open-source community have done a great job of keeping Git commands performance-tuned for larger repos, but VFS for Git is a big leap for repos that cannot be small.

If you are still running an older version of TFS that doesn't yet have the easy import option, that's OK. Usage of git-tfs is a viable solution and Microsoft also has a great write-up for how to approach this manual migration. In either case, there will potentially be work involved if your code-base if you stored a lot of binary files in TFVC compared to text/code.

What git-tfs is actually doing is creating a historical clone of your TFVC repository into a local Git repository by replaying the history and creating Git commits. The tool can be used as a way to bridge a TFVC repo and Git repo, but you are better off fully migrating to Git and removing the TFVC repository.

Once you decide to fully migrate, it's best to do the migration in a few steps locally in the new cloned Git repo before pushing it to the TFS server as the origin. This allows you to clean up any history of binary files that may be needed. The BFG Repo-Cleaner can be used for this which can re-write history in the Git repo to remove all but the latest change to files like binaries, thus reducing the physical size of the Git repo on disk.

Sumo
  • 235
  • 1
  • 6
0

Answering based on using git-svn back in the day:

  1. The source of truth is both repositories. The point of git-* is to juggle this relationship without creating inconsistencies in either repository while migrating. You don't need a "Git server" until the entire team decides to migrate, because Git stores all the history in every copy of the repository.
  2. All files are binary. Git handles files. Ergo, Git can handle binary files. What you may have heard is that if you have an absolutely enormous amount of files (in file count or data volume) in source control something has very likely gone wrong somewhere, and Git may be slower than central version control in some rare cases.

My advice would be to simply try it. Create a local copy of your TFS repository using git-tfs, and run the Git repo through its paces without pushing the changes to your TFS server. If you run into any specific problems they would be appropriate for separate questions.

l0b0
  • 166
  • 8