Recommended workflow for public and private forks of a public GIT-SVN-created repo

Question

I'm trying to set up three things:

1. a public GIT mirror of a public SVN repo
2. a pubilc fork of that repo where multiple contributors can stage patches
3. a private fork of the public repo from #2

I know how to do #1 but am looking for advice on #2 and #3: how to configure, how to keep in sync, things to avoid, etc.

Here's more details:

I'm working with an SVN-based open-source web application whose patch-submitting mechanism is slow and inefficient: patches are attached to bugs submitted in an issue-tracking system, and weeks or months later those patches make it into the trunk.

A seprate problem is that I need to maintain a private fork of the project with additional features that only my company will need. But I want an easy way for my fork to stay up to date with the latest official commits from the trunk.

I'd like to figure out a GitHub-based solution to both these problems. I'd like to end up with three things:

• "mirror" - GitHub mirror of SVN, automatically kept in sync with the latest SVN changes via an automated process (like in this article) that I or another patch-contributor will run. This will make it easy for me or anyone else to create a public or private fork of the project without messing around with SVN.
• "contrib" - for myself and a few patch submitters I trust, I'd like to set up a public fork (or branch?) of "mirror" where we can commit patches we'd like to see eventually show up in SVN. This may also make it easier and more efficient for the core committers to pull patches back into SVN.
• "ourfork" - finally, our company wants ot set up a private fork of "contrib" where multiple devs can add private features which only apply to our company's implementation

Some specifc questions:

• does the approach make sense? Is there a simpler solution we should be using instead?
• how to ensure that "contrib" is kept in sync with "mirror"? Is there GitHub magic to automatically apply new commits as long as they don't conflict? Assuming no, what's a good workflow to ensure contrib stays in sync with its parent?
• "ourfork" will logically be a grandchild of "mirror". What's the right workflow to keep it up to date with changes from both "mirror" and "contrib"? Should I set up "contrib" as my only remote? Or set up both as remotes-- and if so what's the right process for merging?

I read @rq's answer to a similar question and I suspect it answers most of the questions above, but I'm a Git newbie and I'm not sure if his answer applies to my case.

Answer 1

I can't give a complete answer, as your setup is quite demanding.

I would perhaps try to get one of the SVN committers on board. I would then set him in charge of rebasing feature branches in on top of the git-svn clone, and then dcommitting changes back to Subversion. I recently did a very simple example of this workflow in a screencast.

This does require a very tight feedback loop with one of the SVN committers though, and in order to keep history linear, you would have to do a lot of rebasing, which again makes it hard to keep distributed repositories in sync. I'm not sure this will work out for you.