Is it acceptable/good to store binaries in SVN?

Question

We would like to share runtime project binary files. So every team member could take current working version. It is acceptable/good to store runtime binaries in the SVN?

Answer 1

Yes, store it.

We used to store the binaries we delivered to customers in the SVN repository to keep track of it.

Also another use of storing the binaries in SVN (or source control) is if you are providing some internal utility modules to other teams in your company who don't want to build your project to save their build time. I believe it's a common practice.

But we never allowed to store .classpath and .project files of Eclipse (workspace related settings).

Answer 2

Store binaries that not everyone can build. I design chips in Verilog and VHDL and the software team doesn't have those tools. So we store the output binaries in SCM.

Answer 3

There's some contention on this matter but I say yes.

Answer 4

Our Java .jar file builds were binding in their .jar file dependencies, which we were checking into svn. A lot of this was redundant in practice, but we wanted to insure every Java app build we produced had precisely the libraries it underwent QA with.

What really aggravated me, though, with this approach was when I started doing remote connections to the repository and syncing. Would take forever to just churn through all the binary libraries.

We've since abandoned that practice and now use Maven to manage library dependencies - even for projects that we're still building with ant. No more binaries being checked into svn. Life is much better on several fronts because of this shift of strategy. And we have the rigorous control over versions of library dependencies that we desired.

For our .NET builds, one of my developers has devised a solution that works in large part like Maven in respect to all the dependency management stuff, and is achieving much the same benefit there too.

Answer 5

No, don't store binaries next to their source code (unless you have good reasons that offset the disadvantages).

Disadvantages:

• it encourages bad build practices in large projects. The best practice is to fully automate your build. Committing binaries enables you to ignore that: "just manually do the build for the parts that have changed" :-(
• slower updates and commits
• commits which change source code but not the corresponding binaries will cause confusion among developers. How do you detect that there is a mismatch?
• svn update will update the timestamp of your binaries, confusing your build tools which will erroneously think the binaries are newer than your source code changes.
• causes spurious conflicts on the binaries for svn update and svn merge
• it uses more disk space in the repository. (This may be negligible depending on your project.)

In general, avoid committing anything that is generated automatically in a deterministic way from other versioned resources. No redundancy -> no opportunity for inconsistencies.

Instead, use a continuous integration server to automatically rebuild (and run the tests) on each commit. Let this build server publish the binaries somewhere (outside SVN) if necessary.

Now, this does not mean that you should take this as an absolute rule or avoid all binaries. By all means, put your build tools and third-party closed-source binaries inside your projects. And make exceptions when it makes sense. Ideally a new developer should be able to do a check out and immediately launch the build script without spending a day or two on setting up his environment.

Answer 6

I would say that if it makes your team's lives easier, then do it. If it lessens the time taken to set up a working development environment, go for it.