Skip to main content

Living with Subversion and Git in parallel

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

About a month ago, I made my first attempt at introducing my team to Distributed VCS with Git. We agreed that the cost of switching away from Subversion was not a hit we would want to take right now, but we continued experimenting with Git (and Mercurial) migration on the sideline. Waiting a bit longer can't hurt, as  Git continuously gets more support in both Windows and Eclipse.

In the mean time, I wanted to learn git properly, and also get a good grasp of git-svn. We will have to live with Subversion until I can convince everyone of two things

  • git can do the atleast all things svn can do better than svn
  • transition will not be too expensive (technical issues, training, people-friction)
So, I started using git as my tool for working with our Subversion repository. I quickly got into the "porcelain" of git and git-svn, and early on I noticed an unexpected bonus: Git's svn-client is actually faster than Subversion's own client (!). 

So, even though I was the only git-user in a big team using Subversion, I could still use git with many of its advantages:
And the absolute greatest thing about Git is that you get rid of those pesky .svn folders. It's amazing how much meta-shit Subversion spread around in the working directory.  In our rather large project, there were literally hundreds of thousands of files and folders that only exist for Subversion's sake. 

Searching, copying, refreshing the workspace, these operations are down to a fraction of the time they used to take.

The next bonus will be when others want a taste of the advantages it brings to use the Git client. If the project allows it, we can share progress between us in feature branches before finally committing back to Subversion. This could lead to more rapid development, allowing full collaboration on experimental development without having to bother with Subversion branches. 


Read on and get started with your own local git-svn setup:

Import the Subversion repo into Git

First, install Git. I've got version: 1.7.1, for reference.

I got some big help with this from the people in the #git channel on irc.freenode.net by the way.

Read this tutorial on how to convert the Subversion repo into a Git one

Or, you could just try it out:
git svn clone --stdlayout http://scm.yourcompany.com/svn/yourproject
Clone is basically git init plus git svn fetch. The above --stdlayout will try figuring out the historical tags and branches of your repo. It takes a while, as Git will run through the whole history of the repo, and then recreate the necessary history the Git way, compress it, remove duplicates, etc.

In case of a big Subversion repo, after some minutes of importing, Git will fail with signal 13. This is a known problem, but doing git svn fetch again picks up where it stopped. Here's a little shell script that will loop until its done:
while ! git svn fetch; do echo "git-svn halted. Restarting...i"; done

Afterwards, you'll have a Git repo with git-svn set up with the Subversion repo as a remote repository. This means that you can pull (or rather rebase) changes as they come from Subversion:
git svn rebase
or push your changes back to Subversion:
git svn dcommit
I could go on about some more advanced Subversion/Git strategies, and grafting, but this post is already long enough.

I hope that some of you Subversion users will take the time to set up git-svn for yourself. It's really worth it.

Comments

  1. I can only second that, git-svn works like a charm - in fact easier and faster than the official svn client :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Open source CMS evaluations

I have now seen three more or less serious open source CMS reviews. First guy to hit the field was Matt Raible ( 1 2 3 4 ), ending up with Drupal , Joomla , Magnolia , OpenCms and MeshCMS being runner-ups. Then there is OpenAdvantage that tries out a handful ( Drupal , Exponent CMS , Lenya , Mambo , and Silva ), including Plone which they use for their own site (funny/annoying that the entire site has no RSS-feeds, nor is it possible to comment on the articles), following Matt's approach by exluding many CMS that seem not to fit the criteria. It is somewhat strange that OpenAdvantage cuts away Magnolia because it "Requires J2EE server; difficult to install and configure; more of a framework than CMS", and proceed to include Apache Lenya in the full evaluation. Magnolia does not require a J2EE server. It runs on Tomcat just like Lenya does (maybe it's an idea to bundle Magnolia with Jetty to make it seem more lightweight). I'm still sure that OpenAdvant

Git Stash Blooper (Could not restore untracked files from stash)

The other day I accidentally did a git stash -a , which means it stashes *everything*, including ignored output files (target, build, classes, etc). Ooooops.. What I meant to do was git stash -u , meaning stash modifications plus untracked new files. Anyhows, I ended up with a big fat stash I couldn't get back out. Each time I tried, I got something like this: .../target/temp/dozer.jar already exists, no checkout .../target/temp/core.jar already exists, no checkout .../target/temp/joda-time.jar already exists, no checkout .../target/foo.war already exists, no checkout Could not restore untracked files from stash No matter how I tried checking out different revisions (like the one where I actually made the stash), or using --force, I got the same error. Now these were one of those "keep cool for a second, there's a git way to fix this"situation. I figured: A stash is basically a commit. If we look at my recent commits using   git log --graph --

Leaving eyeo

Thirteen blog posts later, this one notes my departure from eyeo after 4 years and 3 months. I joined eyeo around the headcount of 80 employees, and now I think there's just over 250 people there. My role coming in was as operations manager, doing a mix of infrastructure engineering and technical project management. I later on took on organizational development to help the company deal with its growing pains . We introduced cross-functional teams, departments (kind of like guilds), new leadership structures, goal-setting frameworks, onboarding processes and career frameworks.  And all of this in a rapidly growing distributed company. I'm proud and happy that for a long time I knew every employee by name and got to meet every single new-hire through training them on company structure and processes.  At some point, we had enough experienced leaders and organizational developers that I could zoom back in on working in one team, consulting them on  Git and continuous integration

Managing dot-files with vcsh and myrepos

Say I want to get my dot-files out on a new computer. Here's what I do: # install vcsh & myrepos via apt/brew/etc vcsh clone https://github.com/tfnico/config-mr.git mr mr update Done! All dot-files are ready to use and in place. No deploy command, no linking up symlinks to the files . No checking/out in my entire home directory as a Git repository. Yet, all my dot-files are neatly kept in fine-grained repositories, and any changes I make are immediately ready to be committed: config-atom.git     -> ~/.atom/* config-mr.git     -> ~/.mrconfig     -> ~/.config/mr/* config-tmuxinator.git       -> ~/.tmuxinator/* config-vim.git     -> ~/.vimrc     -> ~/.vim/* config-bin.git        -> ~/bin/* config-git.git               -> ~/.gitconfig config-tmux.git       -> ~/.tmux.conf     config-zsh.git     -> ~/.zshrc How can this be? The key here is to use vcsh to keep track of your dot-files, and its partner myrepos/mr for o

Considerations for JavaScript in Modern (2013) Java/Maven Projects

Disclaimer: I'm a Java developer, not a JavaScript developer. This is just what I've picked up the last years plus a little research the last days. It's just a snapshot of my current knowledge and opinions on the day of writing, apt to change over the next weeks/months. We've gone all modern in our web applications, doing MVC on the client side with AngularJS or Ember , building single-page webapps with REST backends. But how are we managing the growing amount of JavaScript in our application? Yeoman 's logo (not necessarily the conclusion of this blog post) You ain't in Kansas anymore So far we've just been doing half-random stuff. We download some version of a library and throw it into our src/main/webapp/js/lib , or we use it from a CDN , which may be down or unreachable when we want to use the application.. Some times the JS is minified, other times it's not. Some times we name the file with version number, other times without. Some