Hacker News Reader

Comment by jrockway | Hacker News Reader

His point about binary files is true. Until it gets as good as SVN at handling binary files then it probably will not have an easy time getting people to convert.

I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)

(Yes, OK, I have a favicon.ico in some of my repositories. This has not detracted from the "git experience".)

View on HN

Of course it's not a backup solution. That's what timemachine, superduper, mozy are for. Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd" To each their own though.

A version control system is such that it can handle versions of the project and not just versions of the source code.

FWIW: I keep whatever files in the project I have uncompressed in git and it hasn't killed my HD space yet.

Let's pretend that you are a graphic artist and you have a psd file with a picture for your website. You make a change that does not work well and your undo history is past it's limit. Instead of having to copy the file, rename it, make changes, and clutter up the folder you have one file with a history and commit messages that tell you what you changed. A commit message of "made the background transparent" followed by another commit "changed the font color to orange" is a lot better to see than a file name of "project_trans_back_orange_v1.psd"

Of course, if Photoshop were Free Software, then you could just make the undo history and the git repository the same thing. That would be the ideal situation.

That would be amazingly powerful. I remember reading something about how convoluted the psd format is because of the backwards compatibility along side new features so I don't know how easy that would be for psd's.

On the plus side, the convoluted backwards compatible nature of PSD files makes it trivial to get useful bitmap data out of any PSD.

I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)

I do small-scale game development (Flash and iPhone) with a team of 2-3. We've always committed image, audio and animation binary files to source control (currently Subversion) so we can track changes, just as we do for code. To be honest, I can't imagine what other approach we should be taking.

Turn 100 developers loose and amazing things happen to your "source code" repository. I used to find entire images of Microsoft CDs in ours. The developers wanted to be able to get to known state for compiling, Visual Studio and anything else they were using went in to CVS, and later subversion. Then because they had so much trouble with different versions of the Visual tools making different output they started checking in all the built DLLs and executables.

The developers should have been soundly thrashed with a cane, but if it is possible to check in a binary. They will do it.

Turn 100 developers loose and amazing things happen to your "source code" repository.

Or don't do that. git users are happy about git in part because they don't work with idiots that misuse their tools.

> The developers wanted to be able to get to known state for compiling, Visual Studio and anything else they were using went in to CVS

That sounds like how Vesta works: http://www.vestasys.org/why-vesta.html (item 3)

If you want to reliably maintain (or even build) a given version of the code, it's the right thing to check in the versions of the compilers and build tools that are known to work. A good tool is small, fast, meant to be run non-interactively, and takes instructions in an easily-reviewed file. Making your official build in Visual Studio is a bad idea for all these reasons--even Microsoft doesn't do that, at least when I contracted there. (They used a make clone with some extra support for metadata from win32 binaries.)

I don't think I've ever stored a binary file in my source-code control system. (Hint: your VCS is not your backup server.)

Backup is not the point. The point is that you should be able to get onto a new machine, and execute your build process, and it should work. If some of the application files are missing, it wont.

I have a favicon.ico in some of my repositories.

It seems that all you're really saying is that your applications aren't media-intensive (binary files limited to an icon), and you don't want to think about ones that are.

Reply on news.ycombinator.com