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