How do you store third party libraries in your source control?

Question

How do you store third party libraries that you use in your project in your source control?

When would you store binaries in your source control?

When would

Answer 1

You should be able to install a fresh OS, get your sources from source control, built and run. So yes, you should put them in source control.

Answer 2

When would you store binaries in your source control?

I store binaries in source control when I want they ability to quickly revert back to the old version of an application. There are number of reason I would do this, those include the following:

• Application testing in an environment that exactly matches production is not always possible.
• The previous programmer may not have used source control or may have used it incorrectly. So it can be difficult to be sure the source code you are changing is the version that matches what the user is working with.

Answer 3

• How: a vendor branch is generally a good approach

• When (thirdparties): for minimizing the number of referential involved: you could add those libraries into a separate external referential (like Maven), but that mean you need to access that extra referential for each of your environment (development - integration - homologation - preproduction - production)

• When (code): for managing the complexity of the changes, when you know updates and fixes for current versions running into production will be needed while new development are in progress.

• Why (store both): for deployment reason: you can manage a complete configuration (list of elements you need) in one referential and query it wherever and whenever you need for:

  • development (you query what you need to develop and execute your code, including thirdparties needed for compilation/execution)
  • tests (integration, homologation): you query the exacts tags you want to update your testing workspace with
  • production: you identify exactly what goes into production from one source: your SCM.

For test and production environments, that also mean your own product (the packaged result of what you are building) should also go into your SCM (only the official releases, not the intermediate ones used internally).
If other projects depend on your product, they will build their own project against your packaged version stored in the SCM, not against your source code they somehow recompiled.

Why this is important ?
Because in the end, what will run in production is that packaged version of your product, not your "source code re-compiled". Hence the importance to make all your test with the target final form of your product, clearly stored and tagged in your SCM.

---

Martin Lazar raises a legitimate point in his answer

Source control is called "source" control, because it is supposed to control sources.

While that may have been historically true, every current RCS have evolved toward SCM (Source Code Management), which does not just control sources, but also manages changes to documents, programs, and other information stored as computer files.
Binaries can then been stored (even stored with binary-delta)

Plus that allows some of those SCM to propose S"C"M feature (as in Source Configuration Management).
That SCM (Configuration) not only stores any kind of "set of files", but also their relationships (aka dependencies) between those sets, in order for you to query one set of file, and to "pull" every other deliveries on which that set depends on (to build or to deploy or to run)