0

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

  • only get what it needs (folders/files)
  • not get any history

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.

Andreas Reiff
  • 7,961
  • 10
  • 50
  • 104

1 Answers1

1

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.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Many thanks! Can I also do a get/clone without history? This does already look promising though. – Andreas Reiff Oct 26 '19 at 11:10
  • @AndreasReiff Sorry, after checking your question again, found that I had a little misunderstanding of your question. Thought you want to only get changed files. But you actually want is getting some specified (folders/files). There is no way to specify part of files to be downloaded during Get source step for now. 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. Also updated my reply. – PatrickLu-MSFT Oct 28 '19 at 02:23
  • @AndreasReiff I think shallow fetch is the closest thing as what you are looking for. If you want to limit how far back in history to download. Effectively this results in `git fetch --depth=n`. If your repository is large, this option might make your build pipeline more efficient. Your repository might be large if it has been in use for a long time and has sizeable history. It also might be large if you added and later deleted large files. – PatrickLu-MSFT Oct 28 '19 at 02:34
  • @AndreasReiff Do you still have any concern about this ticket? If not and my reply helped or gave a right direction. Appreciate for marking it as an answer, which will also help others in the community. – PatrickLu-MSFT Nov 04 '19 at 09:07
  • No, thank you, though sometimes I hope for alternative answer. I marked as answered. Also wondering about the downvotes here.. thought the community was over that for thoughtful questions. – Andreas Reiff Nov 05 '19 at 09:25