Is it acceptable/good to store binaries in SVN?

问题:

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?

回答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)

回答2:

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.

回答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.

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

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

回答8:

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.

回答9:

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.

回答10:

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

回答11:

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.

回答12:

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 https://stackoverflow.com/questions/104453/version-control-for-binaries might be useful!

回答13:

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.

回答14:

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

回答15:

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.