On Mon, Oct 18, 2010 at 10:25 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Seems to me the solution is "Don't store your binaries in Subversion". It all depends upon the binary file type and why you're storing it.
If your build uses GIFs and JPGs, you need to store binary files on Subversion. And, Subversion has no problems with this. Another example of storing binaries in Subversion? In my last job, our help system used Robohelp which produced a wad of HTML files from a Word document. Robohelp had to run on a PC while our builds were done on Linux. Originally, we were attempting to store the resulting HTML (mainly text) files on Subversion, but because Robohelp would completely rebuild everything even with the most minor change, it meant that the techwriters had to delete and add files hundreds of files in Subversion with even the most minor technical document changes. I decided to simply have the techwriters zip up all the HTML stuff into a single ZIP file and store that in Subversion. It made their lives simpler, and it meant that svn log only showed a single file change whenever the help was updated. That ZIP file was binary, but in this case, it was worth storing it inside our repository. But, storing your build output in Subversion? I'd argue it would be questionable in ANY version control system simply because there are better tools that can be used for this purpose. For example, we use Hudson as our continuous build server. Our Hudson process not only creates a new release with each and every check-in (running Unit and Coverage tests), but it also stores the resulting build. We setup Hudson to automatically delete most builds after a certain period of time unless we mark them for QA or production. And, as I just mentioned, we even mark builds in Hudson with their QA and Production status. QA and System admins have no problem locating the correct build to use. You can even configure Hudson to use the results of Project A's build in Project B. And, you can setup Hudson to automatically build Project B whenever Project A rebuilds. So, by using Hudson, there's no need to purge your revision control system of obsolete binaries, your non-developers don't have to use a revision control system just to get the files they want, and something like Hudson automatically handles tracking build status for you. By the way, my actual preference for a release Repository is either Nexus or Artifactory. They provide a well documented (and open way) way of doing the task which means I'm not tool dependent. Yes, they're Maven repositories, but I find them just as effective for non-Maven projects. -- David Weintraub qazw...@gmail.com
