> But this cache is usually not easily transferable to someone compared to them just cloning a repo
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
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?