Our company uses (and supports!) SVN, but I tend to use git. What I want to try is to have git repository - one per project, project developers will be able to pull from this repository (and of course pull from each other if they will want to). But I still want to push all the changes to the SVN, because SVN is being maintained by our tech-support.
I was testing the scenario with following repositories:
The only issue with straightforward usage of 'git svn rebase' and 'git svn dcommit' that I've noticed is that after each push from developer's git repository to the git-svn-clone repository I have to rebase developer's repository as soon as changes will be propagated to SVN and rebased. What I want to achieve is to avoid rebasing after each push.
Please note that I'm assuming that every project developer will use only git repository and nobody will use SVN directly.
I was able to achieve this behavior manually by checking out every git commit one by one in 'git-svn-clone' repository after push and committing those changes to the SVN using SVN client. I believe that 'git svn dcommit' does the same but it also syncs back from SVN and changes commit SHA identifiers which forces me to rebase.
P.S.: --no-rebase option for git svn dcommit didn't help since after first commit propagated to SVN git svn dcommit didn't allow me committing more changes to the SVN until previous one was rebased. I've tried this behavior once and probably could overlook something.
It's actually even worse than that... dcommit changes the commits uploaded to SVN (adding git-svn-id lines, changing the authorship information, etc.) even if you hacked dcommit to not try to rebase.
Basically, git-svn is not able to sync back from SVN ever without doing rebases. A new git<->SVN interface that might remove this limitation is being worked on, but it's not ready yet.
I'm afraid that if you want to keep in sync with the SVN repository, your scenario will not work without rebasing right now.