Drawbacks of using GIT-SVN over other SVN clients?

I would like to start using GIT-SVN to work with an SVN repository. I know that a lot of the benefits of using GIT are still present with GIT-SVN like lightweight bran开发者_如何学Pythonching, and improved file rename/move detection.

But I was wondering if there are any drawbacks that I should be aware of?

Benefits

Here's why I found it valuable, although there may be other reasons for it.

• No need for commit access on a project in order to get started coding.
• Can do revision control on local machines without commit access or even an Internet connection.
• Easier to browse entire revision history (including the SVN history.)
• git-svn rebase is a thousand times better than SVN's built-in conflict-resolution tools.
• You still get some limited benefit from Git's improved branching mechanics.

Drawback

The major crippling drawback: be sure not to do any merge operations or else SVN will freak out when you try to commit. Also, because you're using rebase to sync with the SVN repository, and since pulling from a repository that's been rebased will cause Git to freak out, it's much more difficult to maintain clones of the main Git repository (you may end up needing to delete them and re-clone after each rebase.)

The main drawback I can think of is that the initial clone can be very slow, since you're cloning the entire history of the project. This is true with pure git too, of course, but if you're cloning from a pure git server, it's designed for that. The svn repository is not, so git-svn has to get the history one revision at a time. One solution (other than just letting the clone operation run overnight) is to do a "shallow clone" though then you obviously don't have the entire history, so you have to use svn log to look for very old revisions.

I agree with MatrixFrog that speed is a problem. That's true especially when you clone a project for the first time, but not just then.

Another problem I encountered is that there is almost no support for svn:externals in git-svn itself. And the best solution I could find doesn't always work the way it should.

A couple more I thought of:

• When moving/renaming a file, git doesn't store any metadata that says, "this file was renamed", it just figures it out by noticing that the old file and the new file are very similar. SVN expects you to do the rename through SVN so that it can record some metadata. Git won't do this, so your SVN repo won't have all the history it's supposed to have.
• When merging (or more likely, cherry-picking because of what Max said), the svn:mergeinfo properties won't get set. In fact, I think pretty much anything that uses SVN properties, you can't do though git-svn.

Overall, it's still much nicer than using a standard SVN client IMHO, but there are some definite drawbacks.