Committing binaries to SVN

Question

I've searched around a bit, but haven't found a satisfactory answer, so I'd like to hear your opinions on this.

I have a couple of tools which I have to update and deploy to a few servers every now and then. The source is managed in a SVN repository.

To save myself the bother of copying the binaries to the production servers by ftp or similar means (I have no means of building the projects on the servers), I'm thinking of creating an area in the repository to commit them as well. I could then simply retrieve the most current version of the executables from the svn server whenever I need them.

Since I don't necessarily want to update/commit the binaries every time I work on the source, I would not create the folder for the binaries as a subfolder of my project. Committing the binaries would then (and should) be a separate, conscious act.

--- trunk
    --- project1
    --- project2
--- built
    --- project1
    --- project2

As far as I can see, there should be no problems with this setup. What I'd really like is to then give both the source revision and the binaries a single tag, so as to be able to retrieve everything that belongs together at once.

--- tags/project1/release2/ 
         includes files from 
--- trunk/project1/ revision 487 and
--- built/project1/ revision 488

Is what I'm after possible, and how would I achieve it? Should I instead be looking at some other way of solving this problem?

Answer 1

You may want to read this and this question. =)

Answer 2

Not sure why you don't want to put the binaries under the trunk/project1/binaries tree? That said, nothing should stop you from having the tree look like this:

• trunk
  • project1
  • project2
• built
  • project1
  • project2
• tags
  • project1
  • <tag id>
    • <code as usual>
    • binaries

Answer 3

I believe this handled by the use of "externals". There are pitfalls, though, and I have yet to find something that I feel comfortable with. I do what you suggest, with my source libraries, but I still do it manually.

Answer 4

There's nothing weird about your setup (I'm doing similar things with both build tools and build artifacts when I need to preserve the exact bits.) The layout you want is definitely possible - to "include" specific versions of other branches or tags in your tags/project1/release2, all you need to do is set svn:externals properties on tags/project1/release2 referencing the URL of the sources and revisions you want to pull in, and you're set.

Answer 5

While I can't directly answer your question, I'll tell about an alternate approach.

We have a separate file server for binary releases, with a backup strategy similar to the one for the SVN server, and there is a directory for each project with anything belonging to the project that is not in SVN, including a release directory. The entire history of binary releases is stored in this directory, so you can get the binary from everywhere (well, from within our network) without the need for SVN, i.e. copy it to some production server, send it to the customer or download for testing in a VM. No need to checkout or to rebuild.

I found this setup easier to manage than comitting the binaries to SVN. If you need an exact binary with a specific version, it's just there, provided that the version has been given out to the client (but then, why would you need a binary that has never seen sun light?).

Answer 6

While technically that approach will work just fine, I personally wouldn't use SVN to store binaries like that.

I have 2 reasons why this is the case. Initially I thought that SVN followed in the wake of CVS and didn't store binary diffs, which it turns out I was wrong about. At any rate:

0) "Technically" you don't need to store generated files as they can be re-built if neccessary. Obviously this is not practical in real life, but IMHO you still should be thinking 'how can I build a cache for the generated stuff.'
SVN doesn't really fit that usage model. This is not really a point on it's own, but what I'm trying to convey is "putting something in SVN implies you care about it and want to archive it" - if you don't, you shouldn't IMHO be conveying this message, implicitly or otherwise

1) This is annoying. If someone checks out the top of your repo, they'll get all the binaries as well. If you have more than a meg or two, this is going to make people have to wait for that stuff (and use up their disk space) for no good reason. This can be solved by setting up a seperate repository, but once you do that IMHO you might as well just set up a seperate webserver instead.

2) SVN is designed to keep all your files forever. It is very painful and time consuming to completely remove things from the repository, which makes it questionable to store things that you don't need to store.

I'd recommend that instead you just use a web server to store your binaries on. (SVN is a web server after all**). Keep as many old binaries on the server as you like, and back it up, but you can then delete the old useless binaries once you don't need them any more.

** Yes I know it uses DAV and it's therefore not really just a plain old webserver, but from the point of view of deploying to a production machine, the process is 'I download some files using http from http://blah', so it might as well be one.

Answer 7

@Orion Edwards:

1) Actually, I believe that's not true. SVN only stores diffs, regardless of file contents (text/binary)

1b) That's precisely the reason for the structure I suggested, not storing the binaries as a sub-folder of my project, but in their own, separate area of the repository. That way, you only get them when you really want them.