Git import/export into SVN as a regular workflow?

Question

Randal Schwartz says that he uses Git's SVN import/export feature when he has to interact with SVN repositories. He pulls the project from SVN, does all his local edits/saves with Git then once done pushes the changes back to the SVN repository. Is this really a worthwhile process for daily use with a SVN repositories rather than just using SVN straight up? Especially if your end repository has to be SVN.

Answer 1

Absolutely! I use Git as a Subversion client all the time at work (where our master repository is Subversion for other reasons). I get the following benefits:

• lightweight local branching
• git add -p
• git stash
• ability to share patches or even branches with co-workers who also use Git in this way (before committing to Subversion)
• full repository locally searchable (fast!)

Answer 2

This is a subjective question, but yes, it's absolutely worth it. You'll get all the benefits of Git with none of the hassle of dealing with Subversion locally.

As an extreme example, if you're using Subversion locally, and you accidentally delete some files that you haven't yet committed (maybe you're on a plane and can't commit, for example), you just lost all of your work. On Git, because your repository is local, you can just do

git ls-files -d | xargs git checkout --

Sha-pow! Your files are restored.

Answer 3

When you're locked into Subversion git-svn is completely worth it. The stash feature alone I think makes things completely wonderful. Moreover, you can share with your workmates using Git and not have to have a constant, and usually slow if it's offsite, connection to the subversion server.

Answer 4

This is exactly how I work with subversion because it gives me so much flexibility and speed. I like the ability to create a whole bunch of feature branches on my local machine and merge them back into trunk without polluting the server.

I also love the ability to squash commits together before pushing them back to the subversion server. This reduces the number of subversion revisions I have for fixing retarded typos or adding in some comments. When I integrate a feature branch its a single commit. So if I need to remove it or roll back I'm not wading through a bunch of commits wondering where I actually started and finished it.

Answer 5

There are a couple of guys at work that also do this to our local SVN server. They seem to think it adds a lot of value. It allows them to chop and change the work which may be a blend of issue fix, refactoring, and sytle based changes, into different issues even though the changes are being done at the same time.

I have just got them to build be a git repo for this perposes, so I can also work when offsite.

Plus it's way better for blame/review time tasks.

Answer 6

You haven't fully utilized the power of version control if you aren't in the habit of making private commits of your work, as you go, to your own private branches that don't affect anyone else. Git makes this super easy -- probably easier than any other VCS and way easier than SVN.

It also gives you the freedom to easily commit changes unrelated to the work you're currently doing (e.g. you've noticed an unrelated bug), as a separate commit. You do ensure that each commit you make contains only related changes, don't you? Perhaps no other VCS makes this as easy as git. Past experience with other VCSes has shown me that developers usually get too lazy and tend to commit unrelated changes together... which then becomes painful if one of the changes needs to be reverted. With git, being lazy is harder to justify. You can even test the changes individually before you commit them using git stash --keep-index. If you've only used SVN or the like, power and flexibility like that are almost unimaginable.

Add to that all of the other git bells and whistles, like: rebasing, git bisect (can be a real godsend during regression testing/debugging), git send-email (for quickly notifying teammates about commits you're about to make), doing offline work, the sheer speed, git grep (for searching your version-controlled files), git blame (probably the best "blame" tool around), actual usable branch merging ... I could go on and on.

I and some other members of my team use git-svn as a front-end to SVN for these and other reasons and I can't imagine doing it any other way... well, except for maybe using just git without any SVN at all :P