views:

2509

answers:

4

I've got a 'git-svn' working tree. I'd like to clone a "pure" git repo off this, and then use git push/pull to move changes between the git-svn tree and the git tree, while also using 'git svn dcommit/rebase' to move changes between the git-svn tree and the SVN repo it's based on.

This seems to work okay as far as moving things back and forth between the git trees using git methods, but as soon as I interact with the SVN repo in the git-svn tree, things get wonky -- either I get errors when pushing or pulling between the git trees, or I lose commits in the git-svn tree, or other oddness.

Is this type of SVN <-> git-svn <-> git workflow supported at all or should I just quit barking up this tree?

+6  A: 

I have a bridge setup for some of my projects, but it's only one-way from git to svn (providing a public readonly SVN mirror of our git master branch). However, since it works fine it might help you or point you in the right direction in your two-way scenario anyway, as I assume it's git->svn that makes problems, not svn->git:

My one-way scenario: Existing git repository at github, need a readonly svn mirror of the git master branch

  • Create and initialize the target subversion repository on the Server:
svnadmin create svnrepo
mkdir trunk
svn import trunk svn://yoursvnserver/svnrepo
rmdir -rf trunk
  • Create a mixed Git-Svn checkout and initialize subversion repository
git svn clone svn://yoursvnserver/svnrepo/trunk
cd trunk
git remote add github git://github.com/yourname/repo.git
git fetch github
git branch tmp $(cat .git/refs/remotes/github/master)
git tag -a -m "Last fetch" last tmp
INIT_COMMIT=$(git log tmp --pretty=format:%H | tail -1)
git checkout $INIT_COMMIT .
git commit -C $INIT_COMMIT
git rebase master tmp
git branch -M tmp master
git svn dcommit --rmdir --find-copies-harder
  • Update the mirror
git fetch github
git branch tmp $(cat .git/refs/remotes/github/master)
git tag -a -m "Last fetch" newlast tmp
git rebase --onto master last tmp
git branch -M tmp master
git svn dcommit --rmdir --find-copies-harder
mv .git/refs/tags/newlast .git/refs/tags/last

This two articles from googlecode might help as well:

Christoph Rüegg
+2  A: 

Based on what I've seen, this workflow isn't supported with git-svn, and won't be, due to the way SVN represents merges.

genehack
So this question sits here with one answer for almost a year, and I finally add something so I have something reasonably correct to accept (no offense to Christoph), and then two people pop out of the woodwork to offer versions of the same thing I posted. Awesome. </snark>
genehack
+2  A: 

As I've often said on #git:

git-svn is like a flying car. Everybody wants a flying car, until they realize a flying car is pretty bad as either a car or a plane.

The real solution is to get away from SVN entirely, as quickly as possible. Use git-svn for a one-time migrate, then move everyone over. Git is not that hard to learn.

Randal Schwartz
Your real solution presumes that the choice of moving away from Subversion is available. Short of "move to a new job", sometimes it isn't.
genehack
+2  A: 

One thing that may be causing you trouble is that git svn dcommit will rewrite all the commits it sends to SVN- at least if it's configured to add the SVN metadata note to the bottom of the commit messages. So you will have to adopt a flow where any repositories taking commits from your git-svn workspace rebase against it, losing all the merge history which can't be stored in SVN anyway.

araqnid