Subversion Under Control

Subversion vs. Git

Last semester when I told my real-world-software-engineering-working-friends that I was using subversion (SVN) for my CSCI-362 project, they were pretty much appalled- going on long rants about why I should be using GIT.  I do not remember the points they made back then, so this was a chance to look into it myself.  Based on their reactions, I will have strong feelings about which version control I use when I'm in the working world.

I have VMware Fusion installed on my computer from last semester and decided to add a new virtual machine for this semester (and a couple of back-ups, just in case).  Both GIT and SVN were very easy to install with commands that I googled.

What is version control?

Version control is a system that allows you to keep a history of the changes you/a team make to a file.  So, for example, if you make a commit and at this point in time, your code is working great.  Maybe an hour later something breaks and you cannot find the fix- luckily you can easily revert back to the file you committed when everything was working!  Both SVN and GIT are types of version control that both get the job done, but in slightly different ways.

GIT is the new and cool way of doing version control- which was obvious by my hip real-world-software-engineering-working-friends' earlier reactions.  GIT was developed by Linus Torvald for Linux kernel development.  A lot of googling leads me to believe that GIT is also the most popular version control available at the moment.

GIT is distributed.  And that means...  

Instead of "checking out" a repository, you "clone" the repository which means you get the latest version and all the history associated with that project.  This means you have a complete repository!  Which in turn means that instead of having a central repository (like SVN), GIT has multiple repositories.  The benefits of having multiple repositories is that if something is wrong with the main repository- developers can still work and commit their code locally and then push it up when the main repository is fixed.  A "push" in GIT is like a "commit" in SVN.  Commits in SVN can take time, while commits in GIT are very fast.  Working with GIT is faster because there is no need to communicate to the central server!  And (this point I do remember from my real-world-software-engineering-working-friends) is that you can work OFFLINE.  Very cool.

Team FOSSils has decided to use GIT this semester to broaden our knowledge and to show how "hip" us FOSSils really are.