We are currently in the process of migrating from IBM ClearCase as centralized Version Control to Git / Azure DevOps. It is a large and long grown software project in C# with more than 100 C# projects distributed over about a dozen solutions with some dependencies inbetween, at the moment via Project References.
So far all those solutions were managed with ClearCase in a common folder, however for Git it seems to be best practise to use one solution per repo and handle dependencies cross repo with NuGet Packages.
I wanted to ask for experiences in migrating and splitting such projects, did you come across situations where it was better to include multiple C# solutions in a repo?
How do you manage multiple repositories that belong to one software with one release cycle? We plan on using release branches and I think we have to write a script that branches all repositories belonging to the project or is there a more convenient way, maybe provided by Azure DevOps?
CodePudding user response：
I have written before on ClearCase migration to Git.
In all instances, the scenario was the same:
- don't import the full history, only major labels or UCM baselines
- split VObs per project, each project being one Git repository
- revisit what was versioned in Vobs: some large files/binaries might need to be
.gitignore'd in the new Git repository.
You can still reference all your Git repository (C# projects) in one parent Git repository, through Git submodules.
You can also go the monorepo route: after all, that is what Microsoft is doing with its "The largest Git repo on the planet".
But in that case, you might need to use Scalar, and sparse checkouts.
See: