Local, Central and Distributed Version Control Systems

In the previous tutorial we learnt about Version Control System. Then we looked at challenges faced by software teams in absence of VCS and features of VCS. This article focuses on types of VCS. 

• Local Version Control System
• Central Version Control System
• Distributed Version Control System

Local, Central and Distributed Version Control Systems

Local VCS

Local VCS were developed as a result of first intuitive improvement in the way versions of files were stored. Earlier, versions of files by appending file-names with time-stamps. Ex: GetOTP_9Jan.java, GetOTP_12Jan.java and so on. Local VCS improved upon this crude approach by storing just the difference between these files in a database.

Thus, the first version would be the actual file but each successive version would correspond to the difference between the current and the last version. Difference between two such versions are called patch-sets. In Local VCS, a local database was used to track changes by storing the patch-sets. Any particular version could be recreated by adding the patch-sets up to that version.

As shown in the image above, local database stores Version 1, Version 2 and so on. These versions are groups of related files that have undergone changes since their last edit.

Note: Local VCS had a major drawback of being useful to only a single developer at a time. Thus, several developers working on different systems in a project could not collaborate effectively by using local VCS. 

Central VCS

Central VCS were a step ahead in an attempt to overcome the limitation of several developers using individual local VCS to store patch-sets. Using Central VCS several developers could store their patch-sets in a single location at the central server. In this way, developers gained more visibility of features under development. Administrators also gained better control through the central server to define access-levels of different developers to the code. Developers could now simply download a particular version (also known as checking out) of files from the central server to their local machine. After making changes to these files, they could be  uploaded back (aka committing) to central server. In this way, team-members could collaborate and work from any local machine by simply connecting to the central server. 

As seen in the image above, version database housed in a central server stores different versions of files from multiple machines like Computer A and Computer B. Any local machine can check out any version of these files from the central server.

Note: Though central VCS helped developers and teams collaborate there’s a risk of outage of the central sever. Teams would neither be able to collaborate nor record changes of whatever they’re working on due to such outages. Such servers are also prone to hacking. In such a case, it’d be pain-staking for teams to recover their work. Therefore it’s not advisable to store all changes to code in a single place. 

Distributed VCS

Distributed VCS introduced significant improvement over the risks posed by Central VCS. In Distributed VCS, every local machine would have the copy of the entire code-base (aka repository) along with its history. Thus Distributed VCS moves from the client-server approach of Central VCS to peer-to-peer approach for version control.  That is, in case of Central VCS the central server would serve to requests for latest code from local machines of the developers. However, with Distributed VCS, any of the local machines with the repository and history would serve the requests for latest code.  

Note that central server has the version database containing versions of files. Local machines mirror the same version database. This approach of storing the entire repository in every local machine might seem uneconomical at first. But the teams benefit immensely by using repository cloned in one of the local machines to restore the repository to its original state in event of a crash. It’s also important to note that Distributed VCS doesn’t store exact progressive versions of the files. Instead, it stores just the patch-sets for tracking versions which decreases the volume of history stored on each local machine. Also, developers can record changes in their local machine while working offline. And then upload the new history of versions to the central server for others to view and use after connecting to the network. 

What is Version Control System

Everyone who’s ever written code must’ve had days where they maintain different versions of their files. Whether its adding documentation to your code, rearranging the methods, adding or removing some classes or resources, we’ve maintained several versions. These versions are maintained by using naming conventions like

• GetCustomer_1.java
• GetCustomer_14Mar.java
• GetCustomer_Final.java

Naturally, you must’ve wished for an organized way of storing these versions to see progressive changes made to the code. Additionally, if one’s working in a team with multiple people working on different features, maintaining versions of all features quickly turns into a nightmare. This is just a tip of the breaking point in maintaining your code. In addition to these, let’s take a look at other common challenges faced by software teams.

Challenges in Code Management

Maintain copies of files based on date and time they were changed

While working on a feature to get customer details, one would name the file GetCustomer.java using different naming conventions to track its versions. Ex: Code completed at end of 15 Feb would be named GetCustomer_15Feb.java, followed by GetCustomer_16Feb.java and so on. And if you want to save the code at multiple checkpoints (temporary stable versions of code) in a day then the naming conventions for the file would become even more complicated. 

Track changes made to files by different team-members

Suppose you’re working in a team of 6 members writing tests for a particular feature. It’s imperative to ensure that there’s no duplicate or ambiguous code. Also, team-members should reuse code already developed by other team-members. And also ensure that everyone uses the latest version of code developed by others. This would be an excruciating task for a team consisting of multiple people. Especially if they’re working in different locations.

Trace the file’s history to find the version of code which introduced the bug

Code undergoes regular changes either during development or maintenance phases. It’s quite possible to inadvertently change something that causes the code to misbehave and not work as expected. In such situations, it’d be helpful to view the timeline of changes in code to pinpoint the exact cause of bug.

Maintain back-up of your files

In a unfortunate situation of hard-disk being corrupted or being subject to some malicious virus, working copy of your code is highly vulnerable. As a result, it’s highly likely to lose all of your work in absence of proper backup of your code.

Comment out blocks of code to disable a functionality without deleting it

When the code is still in development, you might write a small sample piece of code to see how a particular method behaves. Irrespective of whether this experimental block of code tests your feature or not, you’d like to retain it for reference. It’s not feasible to maintain multiple versions of files by commenting and un-commenting different blocks of code.

Under light of all these issues, there has to be a better way of maintaining the versions. Hail, Version Control Systems! 

What is Version Control System?

You can think of a Version Control System (aka: VCS) as a kind of database. It lets you save a snapshot of the complete project at any point of time. Every change made to the project files is tracked, along with who made the change, why they made it, and references to problems fixed, or enhancements introduced, by the change. Later when it is required to take a look at an older snapshot/version, VCS shows how exactly it differed from the previous one. 

Version Control Systems (VCS) are tools that help teams manage and track changes in code over time. 

With reference to the image above, on 24 Feb, 17 your project has a new file added to it. This file could be a source-code file, a properties file, an image or any other type of file. Once your project is tracked by VCS, any addition, edit or deletion of files from your project will be automatically detected and recorded by it. In short, every time a change is made to the project, VCS creates and stores a snapshot in form of versions. 

Note: Snapshot is the entire state of your project at a given point of time.

Version Control System also popularly know as:

• Revision Control System
• Configuration Management System
• Source Control Management System

Though different names, these tools simply aid in maintaining tracking changes in your project over time. Consequently teams can focus on business logic and improve its productivity. So VCS are basically a convention of modern software teams to maturely handle code as part of their professional practices.

Next let’s skim through the primary features of a VCS and how they help in overcoming the challenges listed above: 

Features of VCS

1. Maintain independent branches of code for team-members to track their respective changes
2. Ease of comparison of code across different branches  
3. Merging of code from several branches of multiple team-members  
4. Convenience of tracing changes in code to find the version that introduced a bug 
5. Annotate changes with name of author and message in a particular version of code. This helps to easily identify the intent of change 
6. Simple comparison across versions to help resolve conflicts in code during merging
7. Revert changes made to code to any state from its history. 

These striking features demonstrate the great flexibility provided by VCS in terms of code-management. Consequently, software teams have intricately integrated VCS in their daily workflow. Don’t fret if lot of terms in this list of features don’t make sense right now. Detailed explanation of these terms will follow in upcoming tutorials.As part of journey towards becoming an Automation Test Engineer dealing with lot of code, it’s imperative to learn about VCS.

Git is a widely popular Version Control System developed by Linus Torvalds. More specifically, Git is a Distributed VCS. 

Top Version Control Systems

There are many Version Control Systems are available in market, but few top VCS are:

1. GIT
2. CVS
3. SVN
4. Assembla
5. Mercurial
6. Bazaar