I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.
It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it.
As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler.
Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
that's using version control to act as a proxy. AFAIK, a lot of package managers already cache local copies
> You get to ensure what exactly makes it into your application
sorry but i don't follow
> I don't see why merge conflicts would be a problem since you are just replacing a file with a new version
Are you working alone?
But this cache is usually not easily transferable to someone compared to them just cloning a repo.
>sorry but i don't follow
You have the source code to all of the dependencies in your application.
>Are you working alone?
How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency.
right, so they need to download "stuff from the internet". it Doesn't matter much if that stuff is from a remote repo or hosted by a package repository. Except if it's architecture dependent, in which case you definitely don't want to share across architectures. Not to mention they may already have a viable copy in a proxy or cache
> You have the source code to all of the dependencies in your application
I'm afraid I still don't follow
> How many forks of a dependency do you use? Just using the master branch and upgrading along that should be good enough for 99% of your dependency
Well, if I was expecting things to not break I'd never follow upstream master for a dependency.
But the question pertained to merge conflicts. If several people track the same remote and check in dependencies into VCS I'd expect annoying merge conflicts
Or are we perhaps misunderstanding each other? I'm not sure I follow what you mean by forks. Releases are typically on different branches or tags
[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=....
You checkout a project and start it. No downloading required, and no 10000s of files.