git-svn against a monolithic repository

Hiya,

The subversion repository I need to work with is quite odd (by my standards, anyways).

The structure looks something like:

|-- patches
|   `-- foobar
|       `-- project-name
`-- trunk-team-name
    `-- project-name

That is, a single monolithic repository. Each team has their own trunk (as a folder). The patches folder is essentially a production branch for a specific region. Each developer tends to have a branch somewhere else which they use to hack on. When they are ready, the code goes through a review process and then is copied (svn copy) into trunk. It then goes through a build process and is finally merged (in this case, using meld) into the patches where other stuff happens to it.

I would like to use a single git repository for each project. That is, my master branch should relate to the project folder in trunk and my production-foobar branch should relate to the project folder in patches. I could then use git to hack on a local branch and merge to master (and then dcommit back to trunk). When ready, I could then merge master into the production branch (and then dcommit back to patches).

I guess what I'm looking for is something like:

git svn clone https://svn/url -T trunk-team-name/project-name -b patches/foobar/project-name

However, I'm pretty sure that is wrong. Not only does it take forever (I landed up canceling it), but I don't think the git-svn branches will understand the weirdo layout.

I tried manually adding svn-remotes, running git-svn fetch against then and then branching off. However, I started seeing weird things happening when merging (sometimes git-svn became attached to the wrong remote, sometimes it wouldn't update properly, lots of obscure merge conflicts..).

In the worst case, I could clone each project (that is, trunk and patches) separately and manually merge. But if I can get git to do this for me, it'd make a lot of sense.

If anybody has any ideas, I'd be extremely grateful.