I know there is a huge debate about whether you should keep packages in source control or not, but what you are asking for seems like an error prone way of going about getting the same packages without keeping them in source control.
What do you really gain by NOT keeping the packages in source control?
The first step to a repeatable build should be to NOT have much variance. There are a world of scenarios that would increase variance by NOT keeping your packages in source control. What happens if you don't have an internet connection or there is a hiccup?
What happens when someone removes the package from the feed that you depend on? What about when the feed goes down for some reason?
Thanks for the reply, Rob. I see your point. I guess there is a fundamental divide between the java camp (don't ever store binary data in source control), and the .net camp (ok to store binaries).
Without trying to sound preachy about Maven, here is how it happens:
- The pom.xml file contains everything one needs to know about the project dependencies (similar to packages.config).
- Developer checks out code, runs "mvn clean install". This resolves all dependencies from the central repository, sets the classpath, and syncs the local cache on the developer's machine. I could see a command like "NuGet.exe install"
that could do something similar.
- The CI build server does pretty much the same thing before the build.
What happens if you don't have an internet connection or there is a hiccup?
[Maven keeps a local copy of the repository binaries that you have previously used. You cannot add a *new* dependency to your project using Maven if you are offline, but you cannot do this using NuGet either, assuming your feed
is on a server somewhere.]
What happens when someone removes the package from the feed that you depend on?
[This is a cardinal sin in Maven dependency management. Once committed to the repository as a non-snapshot build, ThouShaltNotDeleteOrChangeEver. Yes, this requires a bit of governance and care, since automated builds
and deploys depend on this. ]
What about when the feed goes down for some reason? [Again, cached local copy takes care of this.]
I guess since coming from the java world I somehow feel dirty about storing binaries in source control, when they could easily be resolved at build time. The same goes for generated code, really, which can also be generated at build time. The
biggest issue I guess is space. When a solution has hundreds of dependencies (and dependencies of those dependencies), it makes checking out / cloning projects very slow. This could be a lot of stuff going into source control. To be fair,
running some command to resolve these dependencies after checking out, could also be a bit slow.
In the end, I guess I'm not too worked up about storing the packages, but it just doesn't feel quite right.