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 you store the code in your source control?

Would you ever store both? In what situations would you do this?

(Btw, I'm using .NET but it doesn't really matter for this question)

Answer 1

• 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)

Answer 2

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

As binary or source or both. Depends on the library.

When would you store binaries in your source control?

A third party library for which we don't have the source or an internal library which we haven't made any changes to or the library is too huge to be built around.

When would you store the code in your source control?

Say, we use an internal library A but have made some bug fixed specific to product X. Then product X's depot will keep the source and build it.

Would you ever store both? In what situations would you do this?

Yes, all the latest binaries are stored in source control.

So the tree looks like this:

product

 |-- src   |-- build   |-- lib         |- 3rdparty         |- internal 

...