Version control systems
Introduction
There are different version control systems which have been developed to be used in managing software development projects. The choice of the version control will depend on the model and the workflow of the projects and the nature of organizational workflow that is supported. It is important to understand the requirements of the organization which will use the version control. This will determine the way the version control will suit and align with the goals of the developers. Before a choice is made, it is important to have clear view of the requirements of the organization. This paper will undertake a comparison of the version controls systems that can be used in MDUP Ltd to manage their developers in their development of code. It will make recommendations of the best version control system that suits the needs of the organization.
There two model types of version control systems. The first model is centralized model control while the second is the distributed model control. A centralized version control is one where there is one model of collaboration. There is a centralized workflow. In this model, there is one single hub that will accept the changes from the different developers. The developers will synchronize their work with the central hub. The different developers that are there in the system are nodes and will synchronize their work with the central repository. In this model, when two developers make changes, the first developer will push the changes without any issue. The second developer will have to merge the changes they have with those of the first one. The decentralized model is where developers have write access to their code and read access to the repositories of other developers(Antos et al. 2005).
The model that works best for the MDUP Ltd is that of decentralized. This is because there is a new location, Nottingham, where developers are required to be working from before having new developers in that place. The network of this new place is not guaranteed to be secure. For security reasons, there is a need to have decentralized system where each developer will be having their repositories which will be integrated with the main system after some time. With the fact that there are connectivity problems with the headquarters, the choice of the version control to be taken is decentralized(Allen, Jr, et al. 1997).
Comparison of different version controls
Before making a choice of the version control that is to be chosen, it is important to have a comparison of the features that different version controls systems have. This paper will compare Apache Subversion (SVN), Git, and Mercurial version control. The recommendation will be made from the comparisons(Ball & J. Kim 1997).
Apache Subversion (SVN)
This version control system was created as a replacement for the concurrent version system (CVS). This is a version control which was in use for a long time and was the main version control to be developed. SVN was developed to improve and eliminate the errors that were found in CVS. CVS is free and distributed under Apache License. One of the features of this version control system is that it has atomic operations. This feature enables the control of the operations in the database so that there is no corruption of the database. This is where either all the changes that are made to the source will be committed or no change will be committed to the database. This system does not allow partial changes to be made to the database. Many developers prefer this version control system because it is an improvement of CVS and takes the best features from CVS(Allen, Fernandez, et al. 1997).
Advantages of SVN
One of the advantages of SVN is that it allows for long-term forks which are large and have many directions. This is one advantage which allows cheaper branch operations when the code is being developed. Another advantage is the use of atomic operations which allows for control of the database to avoid corruption of the projects that have been committed to the database. It is an important development that works optimally for most developers.
Disadvantages
There are disadvantages that are associated with Apache Subversion. One major disadvantage is that it does not support distributed working. This means when the server is down, no developer is able to work. This means that developers will not be allowed to have their own versions of the repository. It also does not allow partial changes that are made to the system. This is a letdown for most of the developers because there could be reliable code from the developer that could be useful to the system. Another disadvantage is that it is slow when compared to other version control systems. The version control system is also known to still have file naming issues bugs which make file management hard. There is also lack of enough commands that are used for managing the repository. This limits the management of the repository(Pinnix & Sliger 2006).
Git
This is another version control system that is different and takes a totally different approach to version control. It was developed by the developer of Linux, Linus Torvalds. The objective of Git was to have a version control system that was faster, reliable, and distributed. The version control was developed to be used in Linux environments. This is the reason it performs faster in Linux than in other platforms. There are native ports of Git that are used in Microsoft Windows. These ports are called msysgit ports. Git does not lend itself to projects that are developed by individual users or small teams. This is because it is decentralized in nature. When there is use of non-repository computers, the code may not be there. The high speed of the system is the trade-off that can be used to eliminate this problem(Chou & W. Kim 1986).
Advantages
One of the most admired features of Git is the great speeds with which it operates. The speed is improved when compared to CSV and SVN. There is also the advantage of the peer-to-peer capability which makes the development distributed. There is an also cheap branch operation that is available in Git. There are tools which enable developers to navigate the history of the system. This is where the each instance of the source code has a history tree which shows the changes that have been made to the code. This is important when the developer is developing without internet connection. It allows for offline coding(Fischer et al. 2003).
The version control system has effective and reliable client storage process. It enables clients to pull branches from other repositories. With this capability, it is possible to narrow the amount of history that can be stored on the local repository. There is also the possibility of pruning old revision data and at the same time allowing recent history data to be contained in the repository.
Another advantage is that it is possible to undertake rebasing. This is the ability to take a local branch and change the point of that branch to more recent revision. An example is that there could be a new feature that has been developed for the product. Git will enable that branch to have a recent revision history so that the new feature will be added to the system. The new branch will be changed to reflect the new version. In Mercurial, this is not possible because instead of this, there will be merging of the two versions(Otte 2009).
There is also an architecture which has been developed in Git. Initially, Git architecture was made up of many commands and scripts. This has been improved so that there is one executable file. The many files have been integrated into one library making it easy to understand.
Git has namespaces which are dedicated for each repository. With this, users are able to set mapping between the local branchnames and remote ones.
Disadvantages
One disadvantage is that it presents a learning curve for those who have been used to SVN. It has advanced features compared to other version control systems. Another disadvantage is that it is not optimal when it is used for single developers. It is important to have a distributed systems and a group of developers when using this system. It works best when used in a group. Another disadvantage is that there is limited performance optimality with the use of Windows system. This is because of the architecture with which it has been developed. The POSIX-centric architecture of Git makes it less optimal when operating under windows systems. It was developed to be used in Linux environments. Git can lose history with simple commands. This can be corrected so that the Git server can be designed in such a manner that it will not lose commands(Tichy 1985).
Another disadvantage is that there is no explicit tracking of renaming and copying of files. Git makes use of git-log which is used to look for file names which are identical. This makes the renaming and looking for identical files to be managed effectively.
Mercurial
Mercurial is a version control system which was developed almost the same time with Git. The model is distributed, just like Git. The aim was to compete with Git in working in Linux environment. It is different from other version control systems because it was developed using Python programming language. Other version control systems were developed using C language. This is not to say that there is no instance where C is not used. There are some components which have been developed using C language. Because of the distributed nature of the language, Python developers are privileged with the use of this version language. This is because non-core developers will find it easy to develop new trees and reverting the changes. It has similarity with SVN even though it is a distributed version control system(Spinellis 2005).
Advantages
One main advantage of this version control is that it has less learning curve for SVN users who would want to shift to this version control system. Another advantage is that it has a complete documentation when compared to Git. The learning of the differences with other version control systems will be faster. Another advantage is the fact that it is distributed, thus, allowing for users to make their changes without having to wait for the central server to have the changes. When compared to Git, it requires less maintenance. Git requires periodic maintenance.
Disadvantages
One disadvantage is that it is not possible to merge two parents in the tree. Another disadvantage is that it uses a system which is extensible which is not the case with Git which uses scripts. Mercurial does not allow for history rewriting. This does not mean that this cannot be achieved. It is still possible to achieve history rewriting in Mercurial but with a lot of difficulty. It is slower when network operations are considered. Git takes the credit when undertaking network operations and accessing the systems over the networks. Another disadvantage is that there is no mapping between local branchnames and remote ones. In this version control, there is one namespace that is defined and is shared by all the repositories in the version control system.
Recommended workflow
The development group is made up of three groups, designers, developers, and testers. The designers will each work on their own designs. From the workflow, each programmer will be working on their versions. They will all report to an integration manager who will make the changes to the Blessed repository for submitting. After they are through, they will hand over their designs to the integration manager. It is the integration manager who will commit the final code to the Blessed Code. The designers will have to commit the final code to the Blessed code before the developers start working on the code. Likewise, the testers will have to wait for the developers to submit their final version before testing the whole system. It is after the integration manager gives the go-ahead for the next team to start. This does not mean that the testing will not be done at any stage. It means that the final testing will be done after the system is ready to be used. Since it used rapid prototyping model, testing will be done at any stage. This will make the final system workable and not prone to errors. The project manager will double up as the integration manager. The team leaders of the groups will coordinate with the project manager regarding the stages that their members are in the development process.
Conclusion
References
Allen, L., Fernandez, G. & Kane, K., 1997. Version control system for geographically distributed software development. U.S. Patent and Trademark Office.
Allen, L., Jr, R.C. & Douros, B., 1997. Dynamic rule-based version control system. U.S. Patent and Trademark Office.
Antos, C., Harry, B. & McGuire, T., 2005. Version control system. US Patent App. 11/107,145.
Ball, T. & Kim, J., 1997. If your version control system could talk. In ICSE Workshop on Process Modelling and Empirical Studies of Software Engineering.
Chou, H. & Kim, W., 1986. A unifying framework for version control in a CAD environment. Proceedings of the 12th International Conference on Very Large Data Bases.
Fischer, M., Pinzger, M. & Gall, H., 2003. Populating a release history database from version control and bug tracking systems. In Software Maintenance, 2003. ICSM 2003. Proceedings. International Conference on (pp. 23-32). IEEE.
Otte, S., 2009. Version Control Systems. Computer Systems and Telematics Institute of Computer Science Freie Universität Berlin, Germany.
Pinnix, J. & Sliger, M., 2006. Version control system. U.S. Patent and Trademark Office.
Spinellis, D., 2005. Version control systems. Software, IEEE.
Tichy, W., 1985. RCS—a system for version control. Software: Practice and Experience.
