Wednesday, October 1, 2014

Using SVN as a Git Guy

If you have been introduced to version controlling system through Git and later someday you stumbled upon SVN, then you know what I mean. It feels... weird. And pathetic.

I've been using Git since my second year at university, soon after I started working on software development. I was introduced it at the very first session of BSADD, and later Shafiul Azam vai gave a nice presentation on it. At first it seems to be a little difficult but later I got used to it. The common workflow is easy, clone or fork a project, code, code, commit. Again code, code, commit. Made a mistake? Checkout to last commit. Fix it and commit. Feature complete? Push. Again code, code, commit.

So basically it is just a series of commits, with some push and (sometimes) checkout/reset interleaved with it. Of course sometimes you need to deal with other issues, handle conflicts while working on a team (code conflict, to be clear), delete accidentally pushed binaries when you forgot to put those in gitignore, create branches when you wish to do some experiments and so on. But Git will give you everything you want from it. I don't remember a situation where I wanted something, but Git doesn't have support for it. Besides GitHub has all those goodies - network view, issues page, pull request. (I don't know why but many open source organizations using SVN host their code on their own site, uses that ancient mailing list system and their own version of bug tracker - which in most cases not even close to GitHub in terms of usability).

My first introduction to SVN was during my part-time job at TopOfStack. I had to send codes of a project to a senior developer, so I uploaded my codes to GitHub and send him the link. He said he is not familiar with Git, so I had to send it using SVN. Strangely enough, I couldn't find any quick tutorial on SVN. Probably my fault, I should've search for "SVN for git users". Anyway, I fiddled around it for about an hour trying to figure out how to do basic things like connecting remote repository and push, then gave up at the end. I was under the time constraint, so I decided to send him just a zip file containing the codes, instead of fighting with this seemingly strange system.

I took a deeper look into SVN when I applied to Apertium for Google Summer of Code. Their repository is an SVN one. This time, I found a nice blog post of Abu Zaher vai introducing SVN. Reading that blog post, SVN seems to be pretty easy. In fact, I thought SVN is just some kind of older version of Git, until I had to make my first commit.

In Git, commit and push are entirely independent. I commit changes frequently - whenever I write a method or do some large refactoring or add documentation. After making several commits I push those to a remote repository, generally when a feature is complete and I've finished testing and documentation of that feature. This way the master branch of remote Git repo (typically in GitHub or BitBucket) always remains stable. Another way to do this is to create a separate branch when you start e new feature, do whatever the heck you want to do with that branch - commit, push, then after finishing the feature, merge that branch into the master one. I tried to understand SVN branching, but soon my head started blowing up. It seems to me that in SVN, creating a new branch for implementing a feature is like launching Eclipse to edit a readme.txt. But what strikes me most is that you can't commit locally because you don't have a local repo. SVN dcommit will push all of your changes to the remote repo.

This is especially intimidating if you don't have write access to the remote repository, which happened in my case. You can't push the changes, so you have to create a new repository (oh, I miss GitHub's fork!) and commit everything there - and whenever you want your updates to be merged with main repo, you need to submit a patch for review. Often it takes several days before the patch is reviewed, so if the reviewer wants you to change something and if you've already started working on a new feature on that codebase, things will be messed up. Compare it with GitHub's branch, commit, pull request strategy.

Later, I found the solution - track the SVN repository using git-svn. Do everything using Git in your local repo - local commit, branch, merge. And whenever you want to push your changes to remote SVN repo, perform a dcommit. It's not as flexible as Git, and you would still miss GitHub, but I can live with that.

Anyway, I might be biased towards Git, and I admit I know very little about SVN. So if you find any mistake in my writing, feel free to correct me :)


  1. Interesting, I was reading about SVN just the other day, and assumed to be exactly what you thought it to be in the beginning, a toned down form of git! Now I have a clearer picture.

    Great right up by the way, keep going! :-D

  2. This comment has been removed by the author.