What are pros and cons of using git-svn?

Question

I'm tired of subversion, it keeps corrupting its own repository. As I was for a long time curios of git and always wanted to try it out, I've decided to give it a go and use git-svn. But reading through documentation I realized that you can't use much of git awesomeness with it. You can't use git-pull, it is not recommended to create local branches and there are tons of limitations. Looks like it is not much better than using subversion directly. Or is it? What pros and cons git-svn has over just plain svn?

PS. I'm sorry but I'm not asking you how to fix my subversion repository, I don't care that much. Deleting all .svn and checkout in the same directory overnight works fine. I just was wondering what benefits could git-svn bring to the table.

Answer 1

My experience with git-svn is that it is primarily useful to (experienced) git-users who want to have a git-like interface to a subversion repo. Assimilating both the git set of concepts and the limitations of git-svn was too much at least for me.

If you can, I'd recommend that you switch to git entirely.

I've seen many people complaining about Subversion, but as far as I know it is fairly stable. Are you sure you aren't having hardware trouble?

Answer 2

I can see no trouble to migrate all svn repository to git, keeping history and all other in it, and than to switch to git entirely.

2Gb is to much for a single repository. May be it worth to split it into some parts?

Answer 3

If the usage is:

• "We keep SVN but have Git for quick internal branching", no need to use git-svn: you can 'git init' directly within a branch of your subversion workspace and git hack directly within that portion of your code.

But if this is:

• "We maintain both a central SVN repo and a Git repo", then things are bit more complicated, because:
  • a simple git-svn will reproduce the "SVN branches" (actually simple directory with copies in it), so I would recommend using svn2git and git2svn
  • trying to import everything in one Git repository is not always a good idea (see "What are the git limits?"): if your system is composed of different modules which can be developed independently one from another, they can live within one single SVN central repository, but they should have their own respective Git repo (in order to be able to pull only the modules you need)

Answer 4

Tom Preston-Werner, Chris Wanstrath and Scott Chacon —Git, GitHub and Social Coding: http://developer.yahoo.com/yui/theater/video.php?v=prestonwerner-github

Answer 5

Pros:

• Everything that Git is good for:
  • Network-free access to all old commits
  • Commit and rebase in Git (again, network-free) and then git svn dcommit to push all the changes to SVN for a nice clean commit
  • Cheap local branching (not sure why you say this doesn't work so well)
• Don't have to deal with SVN so much :)

Cons:

• Much better workflow if you already know both Git and SVN (i.e., not so good for new source control users)
• Will confuse anyone else if they look at what you're doing
• Some features of SVN (such as svn:keywords) not available/convenient

Answer 6

I think the change to git will not solve your problems. If you have "non-programmers" inside your working force and they will break others people working copy (I assume by renaming/removing directories or files).

If you will use git-svn or git or whatever other VCS and people still rename/remove their directories, how should this get any better?

I think you should try to train some of the people to understand the basic concepts of VCS.

If the people do not understand SVN workflows, I doubt they will master git-svn, or git.

Answer 7

These are the spesific pro and con using git-svn. So it's not really about the git itself.

Pro:

The tendency of people using svn is to commit big changes all at once, because you need to commit over the wire. This approach can be bad because sometimes the changes might not related with each other. e.g: You can have changes with bugfixes and changes for new feature committed on one changeset. With git I can commit as often to my local git repository (especially when I'm not connected to a network) and have a changeset as small as possible. I then commit to svn (using 'git svn dcommit') when the whole big changes is ready.

Con:

The con of having svn as the remote repository is merging, especially when there are conflicts. It can be painful sometimes. I use IntelliJ as my IDE and to resolve conflicts, I have to go to command line to fix it. Knowing that I encounter this problem often, I have documented it and now it doesn't become a big deal anymore for me.

Answer 8

I migrated to git using git-svn. Our svn repository is still in tact and we still get all of the "git awesomeness". Essentially after the git-svn clone you branch that again as your 'trunk'. Everyone using git will branch from here. When you need to get updates from svn you simply do git-svn rebase and then do git merge --squash from the svn branch to the new 'trunk'. And visa versa. This will mean your history on the svn repo will not match whats in git. When you do more then one merge, at some point your going to have to start grafting commits because the history doesnt match. However if you graft the HEAD of your git trunk to the last commit id that was a squashed merge you will get the same effect.

Ok so let me break this down the best I can with an example.

svn repo: svn://xyz.com/myproject

git svn clone svn://xyz.com/myproject

This should leave you with a normal git-svn setup with a master branch which has the same history as the svn repository.

git checkout -b git_trunk

git_trunk becomes the "trunk" for the git users.

This branch can be used freely like any other git repository.

Now you need to synchronize these two branches via git merge --squash

For instance.. merging from the master svn branch to git_trunk

git checkout git_trunk
git merge --squash master
git commit -a

You would do the same thing in order to merge from git_trunk to the master svn except you would execute

git svn dcommit

This will push it back to svn.

So the complicated part here is that since we are using --squash the merge history is lost and the only common ancestor git will ever know about is the branch point. This will mean merge conflicts. The way i solved it was by doing something like this

Merging from git_trunk to master. First I take the commit id of the last squash on git_trunk. Lets call it ABCDEFG. Then i get the commit-d of git_trunk. Lets say its HIJKLMNO

echo "HIJKLMNO ABCDEFG" > .git/info/grafts

This will tell git when merging that the most common ancestor is the most recent squashed commit.

Its not perfect but it works great for me. Especially now since almost everyone is on git.