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

It's perfectly fine and acceptable to store binaries in the SVN repo. As a sidenote, I can't see why would anyone want to store build artifacts in the repository (I'm not saying you do that).

Answer 2

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

Answer 3

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.

Answer 4

Not for this purpose, no. You should use an external file store, like an FTP or Web server. This way it is easy to download a particular version of your runtime binary without having to update to that revision in SVN first.

Answer 5

The two common reasons you may want to store binaries in a Version Control System are:

• store external third-party libraries.
  Usually one stores them into a Maven repository, but to store them into SVN allows you to have one and only one referential for all your need: get your sources, and get your libraries you need to compile those sources. All comes from one repository.

• store deliveries for quicker deployment.
  Usually deliveries (the executable you build to deploy into production) are built on demand.
  But if you have many pre-production environment, and if you have many deliveries, the cost of building them for assembly, integration, homologation, pre-production platforms can be high.
  A solution is to build them once, store them in a deliveries section of your SVN, and use them directly in your different environment.
  Note:
  This apply also to development elements: if you have a Jaxb process which generates 900 POJO files (through XML binding), and you need to download that development set in multiple environments, you may want 1 compressed file copy transaction, rather than 900 ones.

So yes, it is "acceptable/good to store runtime binaries in the SVN"... for the right reasons.

Answer 6

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 7

I would let my build and continuous integration system handle the latest working version of things, by automatically copying them to an FTP, web or file share for easy access.

Even better I would invest in a CI system that automatically handles build artifacts, I love TeamCity from jetbrains myself but there are others. This way you can handle it fully automatic.

Answer 8

Storing binaries under version control is perhaps defeating the purpose of version control. You are better off using HTTP/FTP..This discussion on SO at http://stackoverflow.com/questions/104453/version-control-for-binaries might be useful!

Answer 9

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 10

At least I store the binaries in the SVN, this way I can quickly revert to the particular version binary and see whether the bug was happening in it or not and trace the version, where the bug was introduced, rather then checking out the whole project, set up all the particular project related and environment settings, and then compile it.

Answer 11

If you're developing in Java, then you can set up a local repository and then use a tool like maven or ivy+ant to access it.

You can upload updates of your local build artifacts back to your local repository as they are ready for others in the company to use.

For other development environments, I don't know what tools similar to the above are available - I have tended to just put them in SVN and be done with it.

I usually use a separate repository for storing third-party libraries to keep them out of the regular development repositories, and have my build files load them in an expected location relative to the project's base folder.

Actually, I use two repositories. One for the minimal files that I need for building my projects (e.g., jar, lib files) and another for the entire third-party package (including the source, documentation or whatever) which I usually store tar.bz2.

That way, if you just want to get the minimum you need to build stuff, you grab the first repository, and if you need to figure out what is going on with, or how to use a third-party package you can start pulling stuff out of the second repository.

It ain't the ideal solution, but it works pretty well.

Here is some more information on how svn handles binary files.

Answer 12

Whenever I see a library in a Subversion directory, I ask the following questions:

• what version is it? (usually you have axis.jar and not axis-1.4.jar)
• why was it included? (especially tricky with dependencies of dependencies)

If you don't have a dependency management system in place, you normally can't answer both questions. And it's the first step to Jar Hell.

I can recommend Apache Ivy (other may swear by Maven) with an intranet repository. Using Ivy, I never had to store libraries into SVN and could always answer the above mentioned questions.

Answer 13

As many have already said, it's acceptable.

Yes, it is convenient to have everything handy from one location, from where you can (for example) checkout an older tag already in binary form with its correct dependencies.

But it is NOT good, especially for backup purposes. We stored all our binaries (and part of the dependencies) in SVN and as the project grew, so that binary section did.

Unfortunately, svnadmin dump just dumps everything, you cannot specify a path of the repository to exclude. Thus, backups (and upgrades of the svn server) became very painful!

If you add that after a not-so-long time in our case those binaries were not useful anymore, I'm sure I will not do that again in a similar case (but I would do for a smaller project).

So I would recommend to think twice before doing that and try to forecast how big can you grow and what else might happen.

Answer 14

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.