1

(( 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:\dev\product_a\v1.0\3pty\boost-1.44\bin\*
C:\dev\product_a\v2.0\3pty\boost-1.44\bin\*
C:\dev\product_a\v3.1\3pty\boost-1.44\bin\*
C:\dev\product_b\v0.9\3pty\boost-1.44\bin\*

... 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:\dev\3pty\master\boost-1.44\bin\*

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.
Improve this question
7
  • What exactly would one do with a binary version control repository? It's not like you could obtain any meaningful information from it.
    – Robert Harvey
    Commented Feb 23, 2015 at 22:20
  • 4
    In general, I would prefer not to have generated artifacts in source control. Instead, rely on repeatable builds. Need a boost library and do not want to compile it yourself? Grab it off the CI server.
    – user22815
    Commented Feb 23, 2015 at 22:21
  • If you're using NTFS, you can create symlinks, you know. So one folder to contain the actual boost files, and a symlink under the 3pty folder pointing to the boost folder.
    – pepoluan
    Commented Feb 24, 2015 at 2:33
  • @MartinBa: In your question, you cite Binaries (should go) in Source Control as evidence that they should, but the accepted answer there states that it is pointless to do so without checking in the entire toolchain used to create the binary. If you just want to "know exactly when and who changed them," maintaining a simple spreadsheet (which includes version and build numbers) can accomplish that.
    – Robert Harvey
    Commented Feb 24, 2015 at 19:58
  • @RobertHarvey: AFAIU, the accepted answer there states the thing with the entire toolchain as an extreme example. (And I repeat: We do not generate many of these binaries.) ... and, Spreadsheet? I refuse to take that seriously.
    – Martin Ba
    Commented Feb 24, 2015 at 20:29

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.