We are thinking of putting our current TFVC team projects into one GIT monorepo.
None of the arguments for or against monorepos have been very convincing. We are having issues with linking different team projects in TFVC right now, which is why we consider a monorepo. We consider GIT since TFVC has serious issues with its merge and detection of file moves. That seems 10-20 years behind what should be possible, even when directly telling the Visual Studio IDE that it is a move and not a delete/add.
I am wondering now about build speed when using a monorepo.
Is the build agent clever enough to
thus speeding up the process?
Or is normally the whole repo cloned, I would have to do any build steps like assembly versioning after the build, only do an update on a new build, and also for good measure (there were always left over files for TFVC) delete the source files on the build agent once a week?
And about multiple build definitions: Does each build definition has to get its own clone of the repository? There would be something like 5 builds in total, totally different solutions and also different branches of the main solution.
Additional info: team is small (we are not Google), whole repo size is ~1-2GB. We are on TFS 2017 right now, with no immediate plans to upgrade.
only get what it needs (folders/files) There is no way to specify part of files to be downloaded during Get source step for now.Unlike using mapping, that appears to only be available when using TFVC.
Since Git relies on the full repository state being present (a commit is a pointer to a state of the working folder which includes all files at that state), it's not possible to just grab some files or folders in the repo.
However, to speed up your build process, instead get whole git repo each time. You could set clean=false and check shadow fetch to only get modified files during build process.
Shallow Fetch: Allows you to download only the latest snapshot of the repository. Will download much faster, but may cause tools like GitVersion to fail (it relies on the history data to calculate a version number).
Clean: False: will retain the contents of the previous build allowing you to do incremental fetches of sources, incremental builds with tools that support it. You can combine Clean:False with a custom step which performs more targeted clean up.
Source Link: How to get modified files alone in TFS Build (Git)
For more details you could also take a look at get source code part of Azure DevOps Git in our official doc.
Besides, if your repo is too big or has too many binaries in it. Consider splitting it into smaller repos, or if it has a lot of binaries, using Git-LFS for binaries.