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

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)