As more and more corporations are expanding their operations globally, the issue emerges of collaboration. Sure, it is feasible to send hundreds of emails back and forth between your project coordinator in San Fransisco and your development team scattered across Calcutta, London and Berlin, but eventually this would lead to a mess of digital data that a new team member would have an impossible time deciphering.
In today's sermon I will address Version Control, specifically the Subversion system, a relatively new development in project collaboration. The Subversion project was sponsored in 2000 by CollabNet as an open-source alternative to previous proprietary version control systems1. Before I go any further however, I should explain how Subversion works through an example...
Imagine working for a software development company like the one I described at the beginning of this post. The whole team is assigned to debug a piece of code with a deadline approaching. Traditionally, people might have divided the project amongst the group members, but this clearly is not the ideal method, because software code is very interdependent and it is important to have all heads working together to think of the smartest solution.
The backbone of any version control system is the repository, essentially a file server, which stores and organizes all revisions to a file. When accessing the repository from a remote location, the user is given the opportunity to not only read and modify the chosen file, but to see details about every single revision in order to see the progression of the project 2. Once the user has downloaded the file locally, they can proceed to make any necessary changes and then re-commit the file back to the repository with comments describing the changes made.
So far, you are probably thinking, "big deal Yan, why would I implement Subversion into my company?" So I say, patience eager beaver, I'm getting there...
La pièce de résistance of Subversion is being able to merge final revisions. Using the same example as before, imagine that Geoff in Geneva had an epiphany while you were busy editing the file. He makes his change and commits it to the repository before you get the chance. Now in previous models of Version Control, your changes will completely overwrite Geoff's and all progress will be lost. However, this is not the case with Subversion. When you try to commit your edits to the repository it will alert you that your file is in a state of conflict. Despite the fact that computers can discover discrepancies between files, it is still up to a human to go through both an make the necessary edits to ensure logical progression. However, Subversion will do its part by giving a side by side comparison of the two files with the changes highlighted. You can then create a third version integrating both yours and Geoff's edits and thus progress is made3.
*phew* That was a long example!
Just who needs Subversion anyways? Well, having used Subversion at the web development company I worked for, I can say that the key niche is definitely software developers. In fact, there are currently 1.75 million developers worldwide use Subversion to collaborate their work 4 . However, this technology could be employed by pretty much any business with scattered employees. For instance, a publisher could have multiple editors proofreading a book, once the changes have been committed by one of them, the others have the ability to access and add their own changes.
As mentioned in the description, Subversion definitely has many positive qualities that are almost essential considering the rapid growth of technology and the globalization of business. With the increasing dependence on technology there are new standards for speed, and Subversion can increase efficiency by taking advantage of the internet in order to bring scattered minds together.
There are however a couple of negative qualities that should be addressed. Eventually after many files and revisions, the repository will begin to reach its capacity and will require some serious resources to maintain servers large enough to handle heavy traffic. Another problem is that not all businesses can successfully integrate Subversion into their model. Even if collaboration is a staple of a company, Subversion cannot help with merging any files that aren't text based including graphics. Maybe as artificial intelligence improves even this will be possible!
I'm done for now... but "Ahhll be bakk!" 5
Sources
1 "Subversion FAQ." Tigris. 2006. CollabNet. 02 Oct. 07
http://subversion.tigris.org/faq.html#why
2 Collins-Sussman, Ben, Brian W. Fitzpatrick, and Michael Pilato. "The Repository." SvnBook. 2007. 02 Oct. 2007.
http://svnbook.red-bean.com/nightly/en/svn.basic.repository.html
3 Collins-Sussman, Ben, Brian W. Fitzpatrick, and Michael Pilato. "Versioning Models." SvnBook. 2007. 02 Oct. 2007.
http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html
4
"Rapid Subversion Adoption Validates Enterprise Readiness and Challenges Traditional Software Configuration Management Leaders." EETimes. 15 May 2005. BizWire. 02 Oct. 2007
http://www.eetimes.com/press_releases/bizwire/showPressRelease.jhtml?articleID=608063&CompanyId=2
5 Arnold "The Terminator" Schwarzenegger
No comments:
Post a Comment