Posts Tagged ‘version control’

Converting SVN repos to Git (for dummies)

August 29th, 2014

We used to use Subversion (SVN) for all of our source control at work a few years ago. Then, we switched over to Git a while back. I had several old projects still stored in our SVN account at and I needed to migrate them to Git repos. A few of them were work projects that needed to be moved to Github. Others were personal projects that I wanted to store on BitBucket. I spent several hours combing through blog posts figuring this out, so I thought I’d make a “dummies” guide on how to do this for people like me who are not Git experts. For this conversion, you will need:

  • Sourcetree – a great, free Git GUI. Get it here
  • Git installed on the command line. Sourcetree has it’s own Git client, but we will need to do some command line stuff. Unfortunately, I can’t offer any tips on setting up Git. I did it several years ago and didn’t make any notes on it.
  • A mac. Sorry, but these instructions are for mac users. They will be very similar for PC users, but may need slight modification.

Once you have those things, here’s what you do:

  1. Create a folder on your machine where you will store your files during this process. I created one called “SVN_TO_GIT” on my desktop.
  2. Log in to your SVN account and find the SVN repo you want to convert. browse through the files and try to get a list of the user ids that have made commits. For example, in one of my work projects, I found the following user IDs:
  3. Create an authors.txt file to convert the old svn IDs to git emails. This is really simple. Just save a blank text file in the folder you created above as “authors.txt”. In this file, add a line for each of the user IDs you found in Step 2. These lines specify how to convert the SVN user IDs:
    andy = Andy Watt <>
    andytb9 = Andy Watt <>
    johnboy = John Doe <>
    john = John Doe <>
    toolbox = Andy Watt <>

    **Note how you can actually re-map the project contributors. I could simply assign all SVN IDs to my email if I want.

  4. Create a subfolder in the SVN_TO_GIT folder you already created. This folder will hold the repo that you will convert, so name it something that makes sense. For this example, I will name mine “REPO_1”.
  5. Open Sourcetree and clone the SVN repo into the REPO_1 folder you created above. Clone it as if it was a Git repo, but enter the URL of the SVN repo. You will probably need to enter your user name and password for the SVN account here.svn-to-git-1-clone-svn
    Sourcetree will notice that it’s an SVN repo and ask you for some details on how to convert it:

    • Create local repository of type: Git
    • Convert from SVN revision: 1
    • Author map file: (browse to your authors.txt file)

    BTW, after you enter your SVN credentials, make sure that Sourcetree is still planning to save your cloned repo into the REPO_1 folder. Sourcetree has a quirk that sometimes changes this destination folder unexpectedly.

  6. Click “clone”
  7. If you get an error about “Can’t locate SVN/”, go here and follow the instructions to get everything hooked up correctly.
  8. Or… if you get a crazy error like this:
    Can't locate object method path via package Git::SVN at /usr/local/git/lib/perl5/site_perl/Git/SVN/ line 338.
    • go to Sourcetree > Preferences.
    • click on the Git tab at the top.
    • near the bottom, change the Git version to “Use system Git”
    • locate the system Git executable file on your machine. You can do a search in finder for “git” and look for a file with that name – the icon will look like a terminal window.
    • that should fix the error


  9. Show the output and check for errors. If it clones successfully, you’re almost done! If not, you probably forgot a user in the authors.txt file. Scan the errors to see if it is bonking on a user id. Add the conversion to your authors.txt file and try again.
  10. Log in to Github, Bitbucket, or the Git account of your choice. Create a new repo. Be sure to specify whether this is a public or private repo. I did not add a readme, but it’s ok if you do.
  11. Copy the url for the new Github repo that you created (in my example:
  12. On your mac, open a terminal window
  13. cd (change directory) to the SVN_TO_GIT/REPO_1 folder that now contains your cloned repo.
  14. run the following commands:
    git remote set-url origin
    git remote set-url origin
    git push origin master
  15. Alternative method if the previous steps didn’t work for you:
    cd /path/to/my/repogit 
    remote add origin
    git push -u origin --all 
    git push -u origin --tags
  16. After it finishes, log in to github and take a look at your awesome new git repo with all of its commit history. Pat yourself on the back for your awesomeness.
  17. Create a new folder on your local machine and clone the new github repo into it. This is the local folder you should work from. Don’t work from the SVN_TO_GIT/REPO_1 folder you created. You should be able to delete that now.
  18. You should remove the old SVN remote and any local references to it on your machine once you’re sure that everything has converted correctly.

If you need to convert an old SVN repository to Git, I hope this will save you some time. If I missed anything, leave a comment and let me know.

Creating a simple iOS game – Bouncing Babies

March 14th, 2013

The first post in my iOS game development series

I like to create games that use interesting gameplay mechanics – things I’ve never seen before, or an interesting twist on a classic game. The problem is that new mechanics are difficult to code. If you want to make something standard, like a Super Mario clone, it’s easy to find a game engine that will do most of the work for you. But new mechanics often require modifying a game engine, or even creating one from scratch. This can be time consuming and frustrating.

I’ve been working on a conceptual game prototype for a while now and it has me pulling my hair out at the moment. To make matters worse, this is a “stripped down” version of a larger game that I want to create. I thought this light version of my concept would be easier to code, but it has turned out to be pretty complex too.

In the meantime, I’m interested in creating a game for iOS. So, I’ve decided to create a very simple game from scratch and blog about the entire process. I’ve never created anything for iOS, so I will have a lot to learn. I also plan to post all of my progress publicly on github, so anyone who wants to follow along can pull my code and see what I’m doing. Since this is a learning process, there will likely be a lot of bad code and blind alleys. And since I have a day job and a family, progress is likely to be slow.

With these constraints in mind, I’ve decided not to design my own game entirely from scratch because I will inevitably add some seemingly simple gameplay element that will derail the entire process. Instead, I’ve decided to remake a classic DOS game from back in the day…

Bouncing Babies was a deceptively simple arcade game that I used to play on my first PC – a Tandy 1000 (yes, I’m old). Here’s a video of the game:

Like all classic action arcade games, the gameplay is simple, but it’s surprisingly addictive. It was one of my favorite games when I was a kid and there are few good remakes of it. Considering my time constraints, this is a project that I might actually be able to finish in a reasonable time period. Additionally, the game code shouldn’t be too complex, so development shouldn’t require any weird hackery (famous last words). I can still do a full redesign of the graphics and animation, but the gameplay will be the same.

So, stay tuned for more updates as I dive into this. This whole project may go down in flames, but I promise it will be an interesting ride.

Here’s a link to the github repo I will be using:

Version Control Throwdown – Git vs. SVN

February 7th, 2013

Version control throwdown - GIT vs. SVNI see a lot of forum threads and blog posts on “which is better – Subversion or Git? The real question should be “which is better for my workflow – SVN or Git?” I’ll attempt to help you sort it all out.

I’ve been handling version control on my projects with Subversion (or SVN, for short) for the past couple of years. I switched to using Git about 6 months ago and have been using it for version control in most new projects. Git and SVN both have their strengths and weaknesses. Which one you use should be based on the type of work you’re doing.

The way I used to handle version control was simple. Any time I made any serious updates to a project, I duplicated all of the files into a new folder and started working. That way, I still had a copy of the previous, stable version if I needed it. This is a ridiculous way to handle it, but it’s simple and it works, as long as you remember to duplicate the files before you begin working.

SVN is an older model of version control that handles this for you. The files live in a repository on a remote server and you create a local copy on your computer (or even multiple computers). “Updating” pulls the latest version down from the remote server and updates the files on your local version that are out of date. “Committing” pushes any local changes back to the remote server when you are done working.  You can revert back to an older version of a project (or even a single file) if you need to. It’s a great way of tracking a project without needing to retain duplicates of every file. It is designed purely for keeping track of project versions – If multiple people try to commit changes to the same files, a conflict occurs, which you must resolve, usually by comparing the 2 files and manually merging them. The goal is to keep your local and remote repos in sync at all times. I used Tortoise as my SVN interface and I’m fairly happy with it.

Git differs from SVN in a fundamental way. It’s a distributed version control system, meaning that it’s designed for multiple developers to work simultaneously on the same project. You again have a remote master repository and a local copy on your machine. The big difference is that when you “commit” a change, the changes are only made to your local repository. Then, when you have finished your work and the local version is stable, you “push” all of your local commits to the remote repository. The idea here is that you can have version control on your local machine and only merge your changes into the master when they are finished and stable.

Git also allows for “branching,” which means that there are different versions of the project stored in different branches. Master is the stable, production branch. Then you could create a branch for a new set of features that you are developing. This way, another developer can make bug fixes to the Master branch while you develop new features on the other one. Then you merge them together later. Git allows for many branches to be created, so different developers can work simultaneously without jeopardizing the stability of the Master repo. I’m not sure why, but Git is also generally faster than SVN for updates and commits. A lot of Git users do everything on the command line – I prefer a decent GUI, so I use SmartGit. Mac users tend to like SourceTree.

So, from my description, it would sound like Git is superior, but that isn’t completely true. It really depends on your project.

Git is designed for large projects with multiple developers working simultaneously. It handles this use case very well. The branches help prevent developers accidentally overwriting each other’s work, or creating instability in the master repository. The downside is that Git has a much steeper learning curve than SVN. I’ve been using it for months and I’m still getting the hang of it.

SVN, on the other hand, is really simple to work with, if you only have one or two people working on a project and the chances of creating repository conflicts are small. So, if you don’t need the “distributed” part of version control, SVN is a great choice.

Another thing to consider is the number of large binary files you will want to have version controlled. Binary files are non-text files, like videos and Flash source files (FLAs). Neither of these version control systems can keep track of changes in binary files, but SVN plays nice with large binary files – Git does not. Git purists argue that large binary files don’t belong in the repository, but I don’t necessarily agree. So, if you plan to have a lot of videos or Flash files in your repository, Git may not work for you. You can tell Git to ignore the large files, but that seems to defeat the purpose of version control.

remote svn repo on a usb flash driveWhich do I prefer? Again, it depends. For my projects at work, Git has been great (unless I need to version a bunch of videos, Then, it stinks). I have a handful of personal projects that I prefer to handle with SVN. I have a USB flash drive on my keychain that contains the remote SVN repositories. So, no matter where I am or which computer I’m using, I can update from the USB drive and work, even if I have no internet access. You can do this with Git too, but since I’m the only developer on these projects, I don’t need the fancy-schmanciness of Git and SVN is less hassle.

Hopefully, this will help you decide which version control system will suit your workflow. If you want to set up a USB thumb drive repository, here are simple instructions for setting up a local SVN repository. Here are instructions for doing it with Git.