On Mon, Oct 18, 2010 at 10:25 AM, Daniel Shahaf <d.s_at_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
qazwart_at_gmail.com
Received on 2010-10-18 17:22:12 CEST