0
votes

We're going to be migrating from in-house TFS to VSTS, but before we undertake that we're going to migrate the existing code from TFVC to Git. But there's a teensy complication I want to get thoughts on...

What we have now is multiple TFS projects (let's call them "ProjectA", "ProjectB", etc). Think of it as multiple inter-related products, but now we want a single "Suite" project and merge everything together. So the new project would be "Suite", with folders underneath for "ProjectA", "ProjectB", etc.

All the work items are under yet a different root project, but we'll have to deal with that situation separately. For now, only the code, only Main, and we can live with a relatively short history (the old TFVC projects will be available read-only for older history lookups). Since there's over ten years of History and a crap-load of branches, we'll need to draw a reasonable line, and I'm thinking 180 days is plenty.

My question & summary: most of the various blogs/articles I've read talk about the more typical approach if creating a new repo in the same TFS project and migrating just that project. We want to create a new repo in a new project, and migrate multiple other projects in as sub-folders, ending up with one single (large) repo. Any caveats I should be aware of up-front?

Once this is done, we'll be looking at migrating the new project up to VSTS.

2
Have you read up on the pros/cons of monorepos in Git? It's generally not recommended to put multiple unrelated applications in a single Git repo.Daniel Mann
How are these things going?starian chen-MSFT
Because all the projects are related & inter-dependent, we're moving towards merging into one. But first we're doing a major cleanup to tidy up a decade of questionable choices (like checking in large binaries). We'll likely end up with one Solution to rule them all. Lots of up-front pain, but we think it'll be worth it in the end. Then comes the pain of the VSTS migration. :-(Brad

2 Answers

0
votes

Like Daniel mentions it's not a great idea to create a mono repo, you should create multiple git repos, use components (Nuget Artifacts) to encapsulate shared parts and consume them from other projects (on other repos). It's much easier to migrate each project to a git repo using the method starian suggest, then you can clone them locally, change the remote to the new server (and single project) and just push that over there. This way you can create multiple repos against the same target project and keep all sub project in their own repo and consume the shared components at your leisure. You can then also rev your components independently from the sub projects which is better. It's a little more effort to start but you'll be better off for the future.

-1
votes

The Azure DevOps server supports import repository from TFVC to git with history. So you can create a new team project and import TFVC repos in other team projects to this one, but not just one git repository, would be multiple repositories.

Import repositories from TFVC to Git