git-svn against a monolithic repository

[Marc Bowes <marcbowes@gmail.com>]

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.