Take a look at the hg-git extension for Mercurial, http://hg-git.github.com/. It allows you to access a Git repository (including pulling, pushing, and committing) using Mercurial. I use it to manage my projects on Github using TortoiseHg on Windows. Haven't had a problem with this approach yet.
You will have "trunk", now called "master", you will have "branches" now called "heads" and you will have "tags", still called "tags", but they won't be folders, they will be "refs", labels to revisions that live in separate namespace inside the repository.
Subversion and Git have different ways to do branching. The basic subversion model is to have a directory tree with single global timeline and if you want to branch, you copy a subtree in another directory.
On the other hand Git has a directory tree with revisions that each defines it's parents, but each revision can have multiple parents (a merge) and multiple children (branches). So instead of having directories for branches, you get independently created revisions. The "refs" are just names associated with latest revision for given "branch".
This difference is fundamental to distributed version control. Git (and other distributed systems) does not have any central authority to keep the history linear, so revisions can be created independently on multiple repositories without knowing about each other and the system has to accommodate them. It turns out the generalization makes branching and merging a lot easier in general.
Note, that in Git, revisions are not on any branch. They just are and branches contain them. But once branch is merged, or proves to be dead alley, you can just delete the "ref" pointing to it and forget about it altogether (if you discard old trials, they will be garbage-collected eventually with git gc). This helps you avoid getting swamped in old experiments nobody remembers what they were about anymore.
Best Answer
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-svntool. 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-svnto 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.