I'm not too sure what you mean about each version of the client patches. Essentially the game download is a project, and the tags are the different released versions. That is fairly standard versioning practice. The question is more about whether to include the game download project with the rest. It's much larger than the rest, and usually requires modifying binary files and disassemblers to update it, so it's more involved to work on that project. It's also perhaps more closely scutinized when a revision is committed to that project, since that stuff is occasionally packaged for download on the main site, and we don't want quality or security problems with it. They're all Outpost related projects, just that one is significantly different from the rest in terms of size, required skills, quality, and security concerns.
Also, SVN uses a binary diff algorithm, so it doesn't matter if the files are binary or text based. Storage requirements on the server for the different versions is proportional to the size of the patch, not the size of the files being patched. If you check out a working copy of all versions, then of course that will require size proportional to the complete file size. That's more where the issues lies. I'm uncertain if the bandwidth requirements to checkout two nearly identical versions is the size of both versions, or the size of the earlier version plus the size of the diff to the newer version. When I did an export, the total bandwidth usage seemed lower than I expected, so it may use the diffing approach, but it also wasn't quite as small as I'd hoped.
I'm leaning towards having appropriate usage documentation and hosting on a faster connection as the best solution. The idea of running the SVN repository on the web server machine has come up, but I'd want to get an OK from BlackBox before going ahead with a plan like that. I was thinking svnserve rather than using an Apache module.