I can't be the only one to think of the Xzibit nested items meme, right? Anyway...
One of the remaining cool things that Subversion does is called "externals." It's a way to point at a specific branch or directory in another svn repository. You can even pin it down to a specific version of a specific directory. Externals are really darn nifty, and would solve this problem in an instant, as changes made in an externals directory are automatically pushed back to the source when doing a commit.
Externals is also something missing in git. Git has submodules, but they don't work in the same way, in that they're tied to a specific commit. This effectively means that there's no native solution to the problem of having "nested" repositories that can be read and written to at the same time and remain perfectly in sync, no less nested repositories using different backends.
If you don't want to do the submodule revision pinning dance, there's another workaround.
Git has decent svn emulation in the git-svn tool. You're probably already using it. The SO question "How do I keep an svn:external up to date using git-svn?" offers us a useful option by abusing that tool.
The accepted answer was simply using git-svn to check out the Subversion repository outside of the tree controlled by git, simply using a symlink to point to it inside the tree. There's a bit more manual work involved in this one, as you would need to remember to commit that specific repository every time you make a change in it. However, it's simple, it's straight-forward, and it is known to work.
Another option entirely would be looking at Mercurial's subrepositories, which can host both git and svn. I'm not sure if you really want to go three levels deep.
I would advise you to stay with SVN for the MS Office documents for two reasons:
- It is already there and it is (in my opinion) better for keeping
Office documents (look here). Has much more third party tools for doing this.
- The lock, though can be achieved in Git, is not "the Git kind of way
of doing things". If you need these features, stick with the tool
that gives you the best solution.
There is a saying that I like that says something like this: "When You're Holding a Hammer, Everything Looks Like a Nail". Just because you are moving to Git to hold you code, it doesn't mean that you should use it to hold your documents.
Best Answer
I did not try this not by myself, but I am pretty sure this is possible when you approach the task exactly in the order you described above:
strip the history of the binary files, only keeping the code changes, in SVN first
migrate to Git afterwards.
Step 1 can be accomplished by moving the binary files with their history into some temporary folder (inside the repo, for example with
svn move). Then you create a fresh copy of them in your projects's local working directory and check them in as if they were new files - so those new files have no history. Then you use the procedure described in this server fault question to get rid of the temporary folder (utilizingsvnadmin dump,svndumpfilter,svnadmin load), which deletes the full history.Note this way whenever you will check out an older revision of the project, the binary files will be missing completely. To avoid this becoming a problem, consider the strategy of keeping the old SVN repo online, as suggested by @RobertHarvey.