2012/3/23 Bjørn Roald <bjorn@4roald.org>:
I have for my own boost repository used git-svn with success against official boost svn. It is slow, but has worked fine for me from a kubuntu box. It is slow with anything involving use of SVN, especially the clone as it is actually fetching all boost history (90000 + commits), but it works.
It's possible that since the point at which you created your clone, the boost repo crossed the line where it has became too much for git-svn to cope with. It's faster to create a shallow clone which only contains recent commits. Something like: mkdir boost cd boost git svn init https://svn.boost.org/svn/boost/trunk/ # Fetch revsion 77000, and don't try to find its history. # This still takes a little while (not hours) and should result # in a copy of the specified revision. If using a different # revision, pick one that actually changes trunk. git svn fetch --no-follow-parent -r77000 # Bring the clone up to date, and then rebase the repo # on to the latest version. git svn rebase This are lots of "Couldn't find revmap" errors because it's trying to reconcile the merge meta-data with revisions it doesn't have.
I have really only used it to track trunk, and I have never tried to push as I have no boost commit access. So as far as a two-way system I really have no idea how well it works except for what bold statements you can find on the net.
It works okay, it does occasionally break history for a moved file when it doesn't detect the move. As you probably know, it's very bad for collaborative work since it's constantly rebasing (rewriting history because changes that were in git are now in subversion, and they're not treated as the same thing). I wouldn't really recommend using git-svn for someone new to git, it's better to first understand how it's meant to work. Bazaar is supposed to have smarter subversion integration, but to do so it tracks a lot more data, so it has no chance of coping with the boost repo.
I find tracking multiple branches with git-svn to be somewhat broken, at least with regard to follow merging from trunk to release in boost. I have not looked into why that is so. It may be that I am missing something, but trunk fit my needs so I left it with that.
It's probably because we don't do proper merges, but cherry pick or do sub-tree merges, or even just copy changes over. If you look at the merge meta-data it's a real mess. I track a few branches in a single repo, it's very useful for comparing them. For example, to see the changes to spirit that are currently in trunk: git diff release trunk -- boost/spirit libs/spirit/