Using Git and Subversion in 5 Easy Steps
I recently wanted to use a distributed version control system to learn and to try it out, since I have been hearing great things about it. The only issue is that my team (and like 1 million other teams universe wide) currently uses Subversion, and trying to get them to switch over would be like trying to punch a redwood down.
But! Not all is lost. You can use git with Subversion. This can give you some of the benefits of using a DVCS without having to change everything you do. I believe you can do this also with Mercurial…I went with git because I had read somewhere it had the best support to working with Subversion. AND RANDOM INTERNET BLOGS ARE ALWAYS RIGHT.
First of all, I will say that I used this as a guide when I was working. It’s a great start to doing this stuff. I’ll also assume you can find and install git on your own, since you’re all-grow’d up now.
Step 1: Creating a local repo
Ok so let’s get started. The first step is to get the subversion library. That webpage I gave you gives you four different ways of doing it, but I decided to go with the fourth option, which is cloning the entire Subversion repository. You can do that by doing:
git svn clone https://svnserver/project/trunk
Now, you should know that this could take a while. You might as well go and eat dinner for the next three days while this completes. Just kidding, this took me about an hour or so while I was working remotely over a VPN, so it’s not so bad. Our project has about 8000 revisions, and about 230 MBs of files.
So you’re probably wondering “But now if I have the whole history, isn’t it going to take like…a bazillion bytes on my disk?” To that I say “Non”…it uses compression, and my git repo ended up being about 1 MB bigger than my subversion one.
Step 2: Create a branch
From there, you can start working in git! The first thing you’ll probably want to do is create a branch:
git branch someNeatoBranch
To change to that branch:
git checkout someNeatoBranch
Now you are working on this particular branch. Note you can do this in one step by doing:
git checkout -b someNeatoBranchwhich will create it and put you on it to work.
Step 3: Commit locally
Now you can edit the files to your heart’s content. And commit locally as often as you like, by doing
git commit -aYou can commit individual files by specifying them, but -a just grabs them all.
Step 4: Commit back to Subversion
Once you’re ready to commit back into the main Subversion repo, first you need to pull all the changes from there, to make sure there are no conflicts. You can do this by using this command:
git svn rebaseThis will pull down the latest code and apply your code on top of it, merging if necessary. Then to commit back to Subversion, you use:
git svn dcommitAnd you will notice that your files are committed back to the repo without any more intervention from you! But where are your comments? Well, all the comments from the commits you did locally will be used to commit to Subversion. It will also do that many commits. So if you did 5 different commits locally, it will turn into 5 different Subversion commits. As long as your team members don’t worry about the revision number spirialing up towards the heavens, it should be ok.
Step 5: Brunch!
This is a pretty simple workflow to get you started on using git with Subversion, but it’s not even half the story. There’s so much more powerful stuff with the branching aspect, and I even haven’t tried it yet to share work with my coworkers before commiting to svn (I’m kinda like a git island at the moment). But try it out, and then check out some of the resources below that helped me get started.
Also, you might want to check how my co-worker James one-upped me. He was working on some highly experimental code that he wanted to share with a teammate, and created a true git repo in approximately 8 seconds, from existing code.
Resources
I had to recently send some modified files to someone so that they could take a look at what I was doing. OH NOES! How do I gather them all up at once?
tar cvzf somefile.tar.gz `svn stat | awk '{print "test -f " $2 " && echo " $2}' | bash`
Word.
To break it down:
The svn stat command is getting all the files that have changed obviously.
The awk command its piped to is the real part that’s doing the work. The awk command prints
test -f file && echo file
Pipe that through bash, and you have commands, which essentially will echo the file if the file is a file. Simple? No? I mean, it will not print it out if it’s a directory, so you don’t have to worry about it adding entire directories.
Surround that whole thing in backquotes (that’s the one with the tilde (that’s the one next to the ‘1′ key ( I’m not telling you where the ‘1′ key is))) and give it as the argument to the tar command.
My adventures with Hardy
I finally upgraded my computer to Ubuntu 8.04, but unfortunately my VMWare server didn’t work any more. That led me into a whole bunch of things that I noticed wrong with my upgrade. Allow me to explain the idiocity.
First, for some reason, even after upgrading, I was still booting into the old 7.10 kernel(2.6.22-14). A quick change to the /boot/grub/menu.lst file cleared that up. I just copied one of the other entries and then modified it so that it pointed to the new kernel (2.6.24-16).
Great. I booted up and then…had no wireless. I had forgotten how I set it up before, until I came across this page. For some reason, Hardy breaks newer Broadcom wireless cards (BCM4312, rev. 02 to be exact). But that page has pretty direct instructions on how to fix your po’ computer…that is, if you have internet…which you probably do, if you’re looking at this page.
Great. Ok now I can install VMWare. I had it installed before, but something made it get all scared and I suppose it scurried away to /dev/null for eternity. Suicide must have been more appealing to the VMWare.
Apparently there are issues with VMWare on Hardy, but following this page seemed simple enough. Except when I ran:
sudo ./runme.pl
It gave me this error:
A previous installation of VMware software has been detected. The previous installation was made by the tar installer (version 3). Keeping the tar3 installer database format. Error: Unable to execute "/usr/bin/vmware-uninstall.pl.
So great, it left pieces of itself behind, except without a shovel to clean them up with. This was easily cleared up by removing the /etc/init.d/vmware directory.
After that, everything worked great. I was able to open up my old XP instance perfectly.
Maven and skinny wars
As I explained in this post here, we used the magical Maven groovy plugin to check when our EAR gets to big, and fail the build. It works great, because now we get instant notification in our CI environment when something is amiss, which might get…um…missed. So our build has been failing lately, intermittently because the EAR has been too big.
The problem was the latest version of the Maven war plugin (2.1-alpha-2-SNAPSHOT) changes the way that skinny WARs are created for packaging in EARs. The documentation hasn’t quite made it to the website yet. Instead of using <warSourceExludes> to exclude the JARs that you do not want, you have to now use <packagingExcludes>. It’s described in this bug here.
