Check out the article and third-to-last comment (as of today) at http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-since-last-month-when-i-used-svn/comment-page-1/#comment-2248 The comment (by Josh) is mine, and details how I've approached this problem. It's worked very well for us, and follows from a workflow presented in Jon Loeliger's "Version Control with Git." I haven't messed with any hooks, but I'd imagine that wouldn't be too difficult. Right now, we keep a couple legacy maintenance SVN branches sync'd up with their corresponding Git branches. The one thing that we haven't attempted (and don't plan on) is creating a new branch in Git that we want to duplicate in SVN. We're only syncing branches that existed in SVN prior to our move to Git. Any new branches are "Git-only." On Mon, Oct 11, 2010 at 3:30 PM, Jan Hudec <bulb@xxxxxx> wrote: > Hello Folks, > > I want to set up a gateway between subversion and git, which would keep the > master synchonized with subversion trunk, both ways, and allow working with > any additional branches independent of subversion. For users it should behave > as any other shared git repository accessed by push and pull. And it needs to > be automatic. > > Did anybody try to set up something like this? > > Background: > > At $work, we are considering switch from subversion to git. However to avoid > big disruptions in the work, we need to do it gradually. So the idea is to > switch to git one by one. The people who already switch need to be able to > test the final workflow with git, while other people still commit to the > subversion repository. > > This basically rules out everybody just using git-svn, because individual > conversions are incompatible (or is there some way to make them compatible?), > so the people couldn't easily share their working branches. > > That leaves me with creating one git-svn repository and having everybody > clone from that. Keeping the repository up-to-date from subversion side seems > trivial (just 'git svn fetch' to it from subversion's post-commit hook). > > The trickier part is exporting changes pushed from the git side to > subversion. My plan is to write a post-receive hook, that will > 'git svn dcommit' to svn trunk. > > I suppose I will have to get the rewritten commit back from subversion and > merge it back to the master. I have not yet tested whether when dcommiting > a merge will properly keep the second parent in the rewritten commit or not. > I can do extra merge if it does not at the cost of slightly uglier history. > > Thanks, > Jan > > -- > Jan 'Bulb' Hudec <bulb@xxxxxx> > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html