Why switch from Subversion to Git more done on the cheap?

Posted Aug 6, 2012 // 3 comments

Git is growing in popularity amongst developers for the technical advantages it has to offer. Many would ideally wish for their clients or their supervisors to make the switch from other source control management (SCM) systems such as Concurrent Versions System (CVS) and Subversion (SVN). To most stakeholders who aren’t involved in writing code, converting to Git wouldn’t make sense from a financial standpoint.

However, there are many reasons using git can help you create better products without hemorrhaging time and money on unnecessary overhead and unrefined process. If you can make the transformation without interfering with your current day-to-day operation, I would highly recommend you do so, and here’s why:

Note: This article aims to bring to light Git's advantages from a different perspective. If you are interested in reading up on the more tech-savvy flavor of this article, look no further .

Concoct Without Fear

Developers strive for experimentation. Of course, it wouldn’t be good if untested experimental code gets committed to the repository and stifles the rest of the team’s progress because they end up troubleshooting bad code that shouldn’t be there in the first place.

Sure, you can set up a model where all developers maintain their own branch, and merge their branch to the master branch when everything is tested and approved. You can pretty much do the same thing in GIT…and more.

Remember that anything you commit to SVN will be pushed to the centralized repository. Git allows you to maintain a personal set of branches for experimentation and development on your own computer without interacting with the repository. That way, you don’t have a bunch of branches in the central repository and everyone has to coordinate which branch is whose. This also allows developers to isolate bad code before it becomes readily available to everyone else. This eliminates clutter and enhances organization and efficiency!

Keep Churning Without Interruption

SCM is a great asset to a team’s workflow if it is readily available at all times. Some say that SVN is great for storing all commits so that, in the event of computer failure, all changes won’t get lost. However, if you send your developer on a flight from New York to Los Angeles to attend a conference, he may not be able to take advantage of SVN since you theoretically need a constant internet connection at all times.

Git works on local and remote branches. So commits can be made on the developer’s computer and pushed to the central server when all is good. This way, rather than losing hours traveling, you can multi task and travel and get some work done!

(Near) Error-Free Development

One gripe I have with SVN is that it does not follow some of its basic SCM principles. In addition to creating branches, you can also create tags, which takes snapshots of the state of a branch (these tags are, in theory unchangeable). It’s implemented more like a recommendation because all you’re really doing is making copies of branches into the tags folder (kind of like how some people copy and paste folders in to their hard drive and append some sort of “backup” label).

It doesn’t mean that no one can make changes to them. You can commit changes anywhere in the repository, so there's a chance of missing changes on the next deployment if, for example, a developer commits changes to a tag (SVN doesn't have a problem with this).  With this, it's assumed that all SVN users follow a certain standard and trusts that no one deviates from the rules.

Git supports the creation of branches and tags...and enforces those principles. You can checkout copies of tags, but you cannot make changes to them, (besides deleting and recreating them again), enforcing it's true intent as a SCM. This way, no one can accidentally commit to tags accidentally and lose changes from current development branches.

Leave No Features Behind

Differentiating changes between files works differently between SVN and GIT. While GIT tracks changes on all files in the project, SVN recursively searches for changes within the directory you’re in. This is nice because you can only focus on a smaller subset of files rather than the entire project. However, I find this erroneous and dirty considering there is a chance of neglecting to commit changes and increasing chances of bugs appearing.

Sure, you could go all the way back to the base level of the project to get a full overview of changes, but again, that’s an added inconvenience that adds unnecessary time and effort to your workflow. I’d rather make sure I know exactly what’s going on throughout the entire project rather than a partially working commit.

Decrease Time Spent On Using The Tool

It is not pleasing to anyone when a large chunk of your time is spent on figuring out how to use the tools and not on the task at hand. It is not difficult to get accustom to using any source control management system, but I can argue that it does take more work to achieve certain goals.

I noticed that some of the syntaxes used in SVN are more cumbersome than their counterparts in GIT. It gets to a point where some copying and pasting is involved (at that point, using GUI like TortoiseSVN or Cornerstone would be faster). For a few examples, see below:

Creating a new branch

SVN

Git

git branch testcode

Creating new tag

SVN

Git

git tag testcode

Switch branches

SVN

Git

git checkout newbranch

Lose all changes from last commit

SVN

svn revert –R ./path/to/directory/with/files/you/want/to/revert/

Git

git stash

Merge branch

SVN

Git

git merge mergebranch 

Personally, I notice myself keeping a crib sheet for the correct paths in SVN (svn info will yield the same thing, too), but it’s still too much to remember and to do, especially when you’re working on multiple repositories. Less typing = better!

Eliminate Bureaucracy in Collaboration

Git is a distributed revision control system, which means that sharing and contributing to projects is easy (of course, one can secure repository for internal purposes using SSH keys and permission settings on either systems). And unlike SVN, where all changes are directly applied to the central repository, GIT allows developers to stage commits prior to pushing them to the central repository.

What does this all mean? When on-boarding someone up to an existing project, you can simply give them access and the URL to the repository and let them experiment and develop on their own without affecting the master branch directly (this way, a peer review process can be included in the workflow more elegantly.  Beats reverting the repository back to a previous state if bad code was committed).

Could you do the same in SVN? Possibly. But, in most cases, time may be spent on training new team members to commit to repository correctly to avoid interfering with fellow team member’s development branches (becomes even more critical when a project gets larger and larger).

Is Git Right For My Company?

Most developers would be delighted if they can change their workflow to use Git. Switching over early would be more ideal unless, of course, your SCM relies on a large network of dependent applications. If it’s not viable to change SCM systems, I would highly recommend using it on future projects.

Git is infamous for having a large suite of tools that even seasoned users need months to master. However, getting into the fundamentals of Git is simple if you’re trying to switch over from SVN or CVS. So give a try sometime.