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

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 2

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 3

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

• 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.

(As noted by ivorujavaboy in 2017: "The only good reason to do this at present day is if you have STATIC libraries that will never change, which is a really rare case")

• 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.

---

That being said:

• Wim Coenen rightfully mentions the disadvantages (bad practice, slow, mismatch between sources and stored delivery)
• Vladimir advocates for the use of a delivery referential (Nexus or, as Vladimir mentions, Apache ivy)
• RogerV illustrates the advantages of using said delivery referential (Nexus in his case)