Is binary dependencies good in source control?

Question

Over the years, I have always kept binary dependencies in the \lib folder and checked this for initial control with the rest of the project. I find that I am doing this less so that we have the restoration of NuGet and NuGet.

I heard that some companies apply a rule in which no binaries can be checked in the original control. Reasons given include:

• Most VCS cannot handle binary files - excellent and merging is not supported.
• Increase disk usage
• Records and updates slower
• The extra functionality, management, and ease of use that the storage manager provides out of the box will be lost.
• This encourages further bad practice; Ideally, projects should look to fully automate their builds, checking for version control is usually a manual step.

Are there objective arguments for or against this practice for the vast majority of projects that use source control?

Answer 1

I highly recommend that you DO NOT use the practice that you are describing (the practice of banning binary files in source control). Actually, I would call it an organizational anti-pattern.

The only important rule:

You should be able to check the project on a new computer, and it should compile out of the box.

If this can be done through NuGet, then it is. If not, check the binaries. If there are any legal / license issues, then you should have at least a text file (named how_to_compile.txt or similar) in your repo that contains all the necessary information.

Another very powerful reason to do this is to avoid versioning issues - or you know

• what exact version of a particular library worked a few years ago and
• if it REALLY was the actual version that was used in the project, and
• Perhaps the most important thing: do you know how to get this exact version?

Some other arguments against the above:

• Checking binary files greatly facilitates assembly automation (and does not interfere with it). Thus, the build system can get everything you need from VCS without the hassle. If you do it differently, then manual actions are always performed.
• The performance ratio doesn’t matter as long as you work on the intranet, and only very little relevance when using the web repository (I suppose we are talking no more than, say, 30-40 megabytes, which is not big today problem for bandwidth).
• No functionality is lost. This is simply not true.
• It is also not true that normal commits, etc. slower. This applies only to large binaries, which usually happen only once.
• And if you have your binary dependencies installed, you have at least some control. If you do not, you do not have them at all. And this, of course, has a much higher probability of errors ...

Answer 2

Things depend on the workflow and the VCS used.

Using a component-based workflow with SVN, you check for included and component libs. Thanks to this, libs and include create an interface for other components. They only import libraries and include the use of svn: externals, without importing the source code of the component at all. This provides clean interfaces and a strict separation between the various components: A component is a black box that can only be used as specified in the interface. The internal structure is invisible to others. Using binary files reduces compilation time and can reduce the number of tools needed to compile, since the special tools needed to create the component should not be present when using it.

However, using distributed things VCS will not work that way. DVCS depend on the cloning of the entire repository. When checking binary files, the storage size will grow rapidly beyond the point where it takes too much time. Although having 100 GB SVN storages is not a problem, since only one revision is considered at the box office, which is several orders of magnitude smaller, having a Git / Mercurial / Bazaar repository of this size will make it completely unusable, as cloning will require age.

So, whether the verification in binary files is good or not depends on your workflow and also depends on the tools used.

Answer 3

My own rule of thumb is that assets created should not be versioned (regardless of whether they are binary or textual). There are several things, such as images, audio / video files, etc., which can be checked for a good reason.

As for specific points.

• You cannot merge these files, but usually they are simply replaced, not piecewise merged. Differences in them may be possible for some files using custom differences, but in general this is done using some metadata, such as version numbers.

• If you have a large text file, using a disk is not an argument against version control. Same. The idea is that changes to this file need to be tracked. In the worst case, you can put these assets in a separate repository (which does not change very often), and then include it in the current one using git submodules.

• This is simply not true. Operations on this particular file may be slower, but everything is in order. This would be the same for text files.

• I think having things in version control increases the usability of the repo. manager.

• This concerns my point of view that the files in question should not be generated. If the files are not generated, then checking and assembling is one step. There is no “binary asset download” stage.