(( The context I have is, but is I think not too important to this question: Windows only development; Visual Studio; mostly C++ with some .NET/C# ))

(I think that) Binaries should go into Version Control, the question is only: Where?

The simplest solution is certainly to just put all (3rd party or self built) binaries that you need in (some subfolder of) your product’s source repository.

The “problem” then is if you have multiple product repositories or when your developers are working on multiple different versions of the same repository concurrently. Which is exactly what we face.

‘Course, we could just keep the binaries where they are and live with a multitude of locally replicated identical binaries and redundant binaries cross repository.

Example:

C:devproduct_av1.03ptyboost-1.44bin*
C:devproduct_av2.03ptyboost-1.44bin*
C:devproduct_av3.13ptyboost-1.44bin*
C:devproduct_bv0.93ptyboost-1.44bin*

… all the bin folders for boost-1.44 will contain exactly the same binary dll, lib and pdb files. Totally redundant.

And each time something’s added to the 3pty folder, every repository’s versions that are checked out locally will have to copy all the new binaries from the server. (Not a big deal, but still.)

(Obviously, there’s package managers like NuGet that may also be appropriate in an “enterprise” environment.)

We have been thinking of moving towards a “simple” solution, where we have one 3rd party repository that is always checked out to a fixed local path, and all projects that need any component just reference the necessary files — and it would work across developer machines and build servers because it’s always the same unique local path.

To get back to the example above, we’d have a separate repository 3pty, and it would just be checked out like:

C:dev3ptymasterboost-1.44bin*

and all projects in any other repository could just reference the stuff there.

Having this inside Version Control would enable easy update of (new) 3rd party binaries and also be convenient when the 3rd party binaries, as with C++, often also contain a lot of header files, etc.

• Is this a valid approach?
• Are there any glaring holes in this approach?
• What would a dedicated (enterprise) package manager buy that this approach can’t do?

_{Note that we don’t use Git, Mecurial nor SVN, so please not specifics or speculation with regard to the type of SCC.}

Addressing some comments:

• The point of putting the binaries under Version Control is to: Know exactly when, and who changed them as well as giving the simplest access and update possible to developers.
• These binaries are not generated artefacts as such. While the Boost example may be built by ourselves, some are 3rd party libs where we only have the binaries.
• Wrt. SymLinks: While I think I’m fully aware of what Junction Points can do, I do not consider them very useful here.