0
votes

Good morning everyone.

We have a historiclly grown TFVC repository (hosted via TFS Version 15.117.26714.0). There was never a branch created, everything is just folders. The current structure is something like:

/project/trunk/application1
/project/trunk/application2
/project/branches/release1/application1
/project/branches/release1/application2
/project/branches/release2/application1
/project/branches/release2/application2

Where every release has multiple bugfix-commits, because we have to maintain older releases for our customers. The first commit is from 2011 and we are going strongly to the 100.000st changeset. Currently we just make commits where ever we like, but since the team has grown, the growing pains also havent gotten any better.

This setup is used in multiple projects.

We would now like to move to a more modern approach of making commits, like feature branches, pull request and easy to do code reviews. Especially the code reviews are currently a huge pain, because we have to cross-check every changeset of relevance.

Sadly we discovered that TFVC is unable to do Pull-Request, so we would like to move to git, but we want to keep our commit history.

For conversioning our TFVC repository to git, we found the tool git-tfs, with which we were able to convert each folder into a single git repository by converting the folders trunk, release 1 and release 2 (from the sketch above) into branches and executing the command:

"C:\Program Files\git-tfs\git-tfs.exe" clone https://dev.azure.com/userName1234/ "{branchName}" . --branches=auto

By adding the other repositories as remote, one can see the branches nicely next to each other.

But this results in A LOT of repositories. In our case it would end up to be 46 (!) repositories for our biggest project. This wouldn't be very nice, to say the least. Also this would mean, that depending on which version we have to create a bugfix for, we have to either change to another repository or search for the release branch from the master branch, which would mean two workflows for something that should be only one.

Is there a way to convert all those repositories into one repository, where the trunk is the master branch and the releases are branches of that master branch? At least from a human perspective, they are nicely distinguishable, as shown in this screenshot of a test-setup of our situation:

Screenshot of a test setup that represents the current state of afairs

1
Did you try to establish a branch hierarchy for your existing branches in TFVC so that git-tfs can treat them as Git branches?Daniel Mann
Hi CAA, any update on this issue? Did you get a chance to implement the solution that we suggested? Were you able to resolve?PatrickLu-MSFT
Uhh, Sorry, didnt See the answer. Will have a Look at it at the weekend. Thank you.CAA

1 Answers

0
votes

The Git-TFS tool is a two-way bridge between Team Foundation Version Control and Git, and can be used to perform a migration. Git-TFS is appropriate if you want to attempt a migration with full history, more than the 180 days that the Import tool supports, or if you want to attempt a migration that includes multiple branches and merge relationships.

However as you mentioned, there are all folders not any branch in TFVC workspace. You should select a branching strategy for them first. And later convert them to Git branch.

Before you attempt a migration with Git-TFS, since TFVC is a centralized version control system,Git stores information about file history and branches in a way that is fundamentally different from a centralized version control system.

  • Git stores history as a snapshot of the repository in time, while TFVC records the discrete operations that occurred on a file. Change
    types in TFVC like rename, undelete and rollback cannot be expressed
    in Git; instead of seeing that file A was renamed to file B, you may
    only see that file A was deleted and file B was added in the same
    commit.
  • Git does not have a direct analog of a TFVC label: labels can contain any number of files at any specific version and can reflect files at different versions. Although conceptually similar, Git tags point to a snapshot of the whole repository at a point in time. If you rely on TFVC labels to know what was delivered, Git tags may not be provide this information.
  • Merges in TFVC occur at the file level, not at the entire repository. You can merge only a subset of changed files from one branch to another, then merge the remaining changed files in a subsequent changeset. In Git, a merge affects the entire repository, and you cannot see both sets of individual changes as a merge.

Source Link

Because of these differences, we generally advise users to do a tip migration and keep their TFVC repository online but read-only to view history.

This is the approach that Microsoft took when it migrated Windows and other products from centralized version control to Git.

For tip migration, kindly refer the official TFVC import tool(single branch based).

For using git-tfs, you could follow Daniel Mann's suggestion establish a branch hierarchy for your folders in TFVC so that git-tfs can treat them as Git branches. A command for your reference git tfs xxx branch -init --all

As for how to establish branch for folders, you could take a look at our official tutorial convert a Folder to a Branch.