I'm not sure why this ever got downvoted, because it's a key point. Unless you've got some kind of exclusive check out/check in type facility, working with unme

I'm not sure why this ever got downvoted, because it's a key point. Unless you've got some kind of exclusive check out/check in type facility, working with unmergeable binary files is going to prove a pain. It's no fun having people find out once they come to commit/check in/merge/etc. that they've got the unenviable choice of losing their work, or losing somebody else's... or losing both. (The disk space problem is far less of an issue - disk space is cheap, and networks are pretty fast, so up to some medium repository size of (I suppose) hundreds of GB you can actually just let it build up. This doesn't scale completely, but for many projects, possibly even most of them, if everybody has a copy of absolutely everything, it's no problem.) For whatever reason DVCS users often have a bit of a blind spot in this regard. Because DVCSes are good, the thinking often seems to run, if DVCSes handle something poorly, that must be something that revision control simply isn't to be used for. ("You must be using it wrong. Try storing everything on a shared drive and take daily backups and coordinate access using physical tokens.") Which is wrong, because revision control is for everybody, not just the programmers. People who work on unmergeable binary files need it too. But fortunately, even if git/etc. and their users doesn't care about you, you're not completely stuck. if you have lots of binary files your needs are fairly well served by Perforce, and you can probably get on OK with SVN and its locking facility.