Let's discuss one more scenario. Suppose we developed code yesterday and have already shared it with the team. And now our teammates are using it. But now we want to change it because there is a possibility to have one more kind of solution or the client requirement has been changed, or some other reason. A change is never a problem; the problem is in keeping the old code as well as the new one; not only for the one who developed the code, but also the one who received it. Changing the code frequently and keeping it for use frequently is a big problem. It's not only a pain but also frustrating to know what changed, when, and why? We need an easy, practical solution.
The process which helps us to track a file for all of its changes and all of its revisions is called versioning. Using versioning, we can keep the original file and all of its step-by-step changes as well. Each changed file will be a new version of the old file. As all of the versions are available, any point when we feel like using a file from xxx version, we just have to get it. We not only store the file but versioning helps to distribute the files so that we will get relief from sharing them manually.
As versioning has become a very important part of software development, there are many such tools available. These tools are basically divided in two categories:
Centralized versioning
Distributed versioning
In centralized versioning systems, a copy of the application will be kept on a centralized server from where the developers will take the file or commit their changes to the server. Examples include Concurrent Versioning System (CVS) and Subversion.
CVS is very old tool which was created in the Unix operating system in the 1980s. It was very famous among the developers of Linux and other Unix-based systems; cvslut was developed for Windows servers. CVS uses a central repository of files to record the changes done in any file by the developer in separator directory. If the developer wants his changes be made available to other developers, he will commit the code to the repository. Now, along with the previous version file, the new version also will be recorded.
Though maintaining the main flow of development has made things easy but the branching is not. Sometimes the developers can do parallel development of the products with unique features which they can combine later. This process is called branching.
When we rename a file due to some reason or even the location of the file changes, then it is supposed to be tracked by the SCM (supply chain management) but CVS cannot update the version in these cases, which is not good.
CVS supports a first come, first served basis, so it's quite possible that some changes will not be reflected or conflicted.
Apache Subversion was developed to provide an alternative to CVS. The aim was to fix up the bugs in CVS to maintain high compatibility. It's an open source, where either all the changes will be made or none of them. This feature helps the developers to get the correct, latest revision of the file from the repository. Branching is well supported in SVN.
The best thing about SVN is that a wide range of plugins has been developed, which can be integrated with numerous IDEs to support SVN. The problem of keeping a history of renamed or relocated files has been removed in SVN.
Along with these good things, there are some problems. The biggest problem is what if the SVN server is down? No one will have access and then versioning is not possible. One more issue is about the speed associated with SVN.
Let's now have a discussion in depth about SVN as we are going to use it throughout the book.
As we already know, SVN is an open source version control system which can operate across the network. Its development was started in early 2000 by Collabnet. In initial development, the base was CVS but without the bugs in CVS. This development was started by a team of Karl, Jim, Jason Robbins, and Greg Stein to name a few. This development finished in 2001, from when the developers started using it. Though in the beginning, developers started with CVS as a base, later they started from scratch and developed a fully-fledged new product. In 2009, Collabnet started working with developers to add it to the Apache Software Foundation. They succeeded in 2010.
There are two consistent parts of Subversion: one is the repository which stores all of the versioned data and the other is the client program that manages the local reflections.
The architecture of Subversion
The central store where all the versioned data is stored is called the repository. The repository normally stores the data in the form of a filesystem tree. A number of clients can get connected with this repository to pass the data in the repository so as to make it available for other teammates. If any teammates want to get the data, they just have to read the repository and the data will be available. The repository keeps a record of each and every version of a file. The repository doesn't only give the reflection of the changes but helps the developer to check what changes have been made, who made them and when. Also, if they are interested in any specific version, they can read it from the repository.
So a version is nothing but a new state of the file where the changes took place.
The repository and the sharing of files
Now, we need to understand here the stages of a file.
If any developer creates a new file in his local system, it's not yet known to SVN. So the first task of the developer is to copy this file in SVN, which is called as svn add. Whenever we write the file (new or modified) to SVN, the process is called as committing. Once the file is committed, it's under SVN and now can be available to other team members. But to use this file, other team members have to take this file into their local system; this will be called as checkout. Once any developer gets their file, they are free to use it the way they want. Now, this local copy file will be known as a working copy.
We can use SVN through the command line. But then we need to remember all the commands for different operations. So instead of using the command line, a UI application can be used. This can be used to commit, checkout, and update the working copy. One such free application with an easy UI is Tortoise SVN, which has been implemented as a Windows shell extension. Using Tortoise SVN, developers can get rid of the command line. Tortoise SVN can easily be integrated in IDEs such as eclipse and Visual Studio.
Opposite to centralized versioning, in distributed versioning all the copies of an application will be kept on the developer's machine, for example, GitHub.
In opposition with CVS and subversion, GitHub uses a radial approach. The basic idea behind GitHub is to speed up versioning. GitHub is also developed on Linux. But it is also available on Unix native ports of GitHub and Windows operating systems. This being a non-central server, it doesn't lend itself to single developer projects or small projects.
A good thing about GitHub is that it helps the user to navigate through the history of the file. Each instance of the source contains the entire history tree so as to track the changes even when they are not connected to the Internet.
Due to the availability of the tracking of files, branching is well supported by GitHub, but it has limited support for Windows.