We currently have everything under one big SVN directory. I use git for personal stuff so it's always a pain to work in SVN.
Think about how the Linux kernel works. A single person at the top who has final say in the final product, a lieutenant responsible for each smaller group working on one subsystem.
Insist on keeping your history clean. Good commit messages and comprehensible changesets are necessary to make sure the code is understandable by code review, future maintainers, and when different teams' code needs to interoperate.
I'm working on moving a dev team from SVN to git myself; the plan that people seem to be happy with is to use git as a drop-in replacement for an iteration or two while people get used to the new tools, and then start introducing people to the more advanced features as and when they seem appropriate, hopefully ending up with a git-flow style workflow.
See http://nvie.com/posts/a-successful-git-branching-model/
Using a CI server to test merging branches back to master and running the tests make it a lot easier to know when its safe to merge back to master (I left a comment in the comments earlier about how this can be done).
In SVN is easy to create repositories. Not as easy as on GIT, but very easy.
Also, you can attach different commit-hooks to every repository, related to each project.
You can make git-svn work for non-trivial setups but it took me a lot of trial and error, failed merges and git stashes to make it work for me.
Right now I have this workflow:
git add filename(s)
git stash
git svn rebase
git svn dcommit
git stash pop