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)