e-issn 2455 1392 Volume 2 Issue 6, June 2016 pp. 449 455 Scientific Journal Impact Factor : 3.468 http://www.ijcter.com A Comparative Study on Different Version Control System Monika Nehete 1, Sagar Bhomkar 2, Dr. Jyoti Kharade 3 3 Professor. Varsha Sharma Department of MCA 1,2 Bharati Vidyapeeth s Institute of Management and Information Technology, Navi Mumbai Abstract Today many software projects are using version control systems for maintaining their software source code. There are many version control systems, and the choice of which one to choose is far from simple. Today the two biggest version control systems are Subversion and Git. In this paper we have found the main differences between the two, and explore how the choice between them affects software developers. Although software developers in many aspects are unchanged by the choice, we did find some interesting findings. When using Git, our empirical study shows that software developers seem to examine in their code to the main repository more frequently than they do when using Subversion. We also find indications that software developers tend to use Subversion with a GUI, whereas the preferred UI for working with Git seems to be command-line. We were also surprised of how insignificant the learning aspect of the system seems to be for the developers. Our goal with this paper is to provide a foundation to stand upon when selecting what version control system to use for a software project. Keywords Git, Subversion, VCS, Version Control System, Revision Control System, comparison I. INTRODUCTION A version control system is a expensive tool in the area of software development, and is mainly used for tracking and managing changes done over time to content of files(for example software source code).a version control system keeps logs of a file to see if there is more than one developer that is trying to change the content of a file, and manages the merging of the changes to intercept content from being overwritten. A version control system also stores historical versions of files. The basic version control idea is to keep files separated on which programmers work on, called as working copies, from the master copies, which are stored in a repository The programmers never work on the repository. They take an check out in their working copies from the repository, make changes, and then check in (commit) their changes. Every time a programmer commits a file, the version control system creates a new version in the repository. In this way, the repository contains all versions of a file. Following are the metrics use to evaluate each tools. Repository Structure: A Repository is generally created with three directories. @IJCTER-2016, All rights Reserved 449
1) Trunk : The trunk is the directory where we create the main repository. During the development and design phase the development team works on this directory We added the beginning version of the repository in this directory. 2) Branch : At the end a sprint or a minor release, the code in the trunk is frozen and released for Validation. We created a Branch from the trunk to replicate this phase, after checking in the first revision. Part of the development team works on resolving bugs reported by the Validation team and commits them to the branch. At the end of Validation phase, the changes are moved to the trunk to prevent these bugs from resurfacing in the next release. 3) Tag : Tag basically, is a checkpoint that is created during the development phase. We tag the trunk when we build a new branch, to set up a restore point if something goes wrong. After a tag is created, the trunk is released for the next phase of the development, while the branch is used for Validation. II. LITERATURE SURVEY Today, two models of version control exists as, a centralized- and a distributed model. 1) Subversion (SVN) and the centralized model : The centralized model include storing the version history on a central server, while developers are working on local copies of the files.this means that a developer needs network access to perform version control operations. If a new branch is created or file is changed in a version control system using the centralized model, each client will be able to see the change. The most successful centralized version control system today is Subversion. Subversion was created in 2000 by CollabNet Inc. as an enhancement of the version control system called CVS (Concurrent Versions System). Today, Subversion is developed under the Apache License as an open source project, and is the most commonly used centralized version control system. 2) Git and the distributed model : With a version control system that uses the distributed model, a complete local repository is stored on the client computers. There can still be a central server to which developer can share their new changes when they are ready, but they will also have access to the full history without any network connection. In other words, all changes made are only stored locally, until the developer decides to publish them to the main repository, on the server. Git was developed in 2005, by the Linux development community. Fig. 1. Centralize System(SVN) @IJCTER-2016, All rights Reserved 450
Prior to 2005, BitKeeper (another, commercial, distributed version control system) had been used to manage the source code for the Linux kernel. BitKeeper was initially free to use for open source development, but after the company behind BitKeeper decided that it would no longer be so, the Linux development community quickly developed their own, open source version control system and abandoned BitKeeper.Today, Git is the most common version control system that uses the distributed model. Fig. 2. Decentralize System(Git) III. METHODOLOGY Every Version control system has following basic operations. 1) Creating or Maintaining Repository : Subversion: The VisualSVN Server tool has a GUI that clarify the task of performing various admin functions such as creating a new repository, managing permissions for each user and adding new users, creating groups and managing permissions. We created a repository that has three directories, that is Trunk, Tag and Branch. Then, we added the latest version of the application source (version 6.4.1) into the SVN repository using the Visual SVN GUI. We worked as a team, and each of us downloaded the latest versions of the code and applied the changes from the next version of the source (version 6.4.2). Git: The master repository was organized on a web hosting service that used the Git version control systems. Master repository is created on the hosting provider using their respective GUI. Since Git uses a local repository on the developers workstation, we then initialize a local git repository using the git init command. Now a developer has two options: start developing her/his project or clone an existing git-enabled project and then work on that. Cloning of the remote master repository is done using the git clone command. Before we began the basic operations as part of the standard development process, we evaluated the time it took to make a local copy of the shared central repository. We discover that even Subversion server was local and git is on web server. The amount of time to make a local copy somewhat more with respect to Subversion. Git was much faster in cloning the entire repository. @IJCTER-2016, All rights Reserved 451
2) Add and Delete Code: Subversion: While working on adding sources from the next revision of the Source, we identified a few files the were new in one of the upcoming versions and they were not revisioned yet. With Subversion, we used the Tortoise Svn client to append these files to be versioned in the trunk. This is convenient and easy to use, as the new unversioned files are not pointed by subversion and the SVN client clearly indicates upon subsequent commit to the repository. Also, we deleted a few files to check how SVN works. We can delete files using the delete command by the Tortoise Svn client. This was reflected in the central repository after the next commit. Git: We now need to add the source code to the local repo. For this we added the file from the project onto the staging area so that they can be committed to the local repo. This is made using the git add command. This way the git utility will show which of the files are unversioned and will add only those file to the staging area. Performing the same action as we did in Subversion we remove files from the current working directory. This was done using the git rm command. 3) Commit and Update local Rep: Subversion: In order to keep the local repository up to date with root repository, we did an update using the Tortoise Svn client on the root directory of our local repositories. This did not affect the changes made to the local copy, rather just get the commits from other team members. We then, added changes from the next version of the code and committed changes. Git: After making changes to the working tree we select to stage and commit the files to the local repo. Staging of the files for commit was performed using the this command. Committing a file to the local repo required us to provide a commit message which will be associated with that commit. This is specified using the -m option with the git commit command. On performing the commit operation, we receive an output which gave an concept of the changes made to the repo. 4) Branching: Subversion: With Subversion, it is simple to create a Branch. We first tagged the source in trunk, after freezing the code. Then, created a Branch for whenaver release version to simulate Validation. Changes done to the branch can be merged to the trunk anytime it is ready. Since, we used the Tortoise SVN client, we had the flexibility of doing the merge using a powerful comparator and diff editor. Git: reating branches with Git is extremely simple. We normally run the command git branch branch-name to create a new branch. Switching to the new branch was just simple running git checkout branch-name. A branch in Git is a small 41 byte file which contains the checksum SHA-1 checksum of the commit that the branch it points to. 5) Conflict Resolution and Merging: Subversion: This is one of the main tools that is quintessential in performing version control. After creat- ing a branch, any bugs that are found during Validation is reported and fixed on the branched code. After the Validation phase is complete, we need to combine these changes back in the trunk. This is important because, the branch code solve some critical bugs and it is important that the next release has the right fixes in trunk. The Merge tool issued with the Tortoise SVN helped us in performing this operation more successfully. We used this tool to extract the changes from the Branch into the Trunk. We merged the files that were modified @IJCTER-2016, All rights Reserved 452
using the comparator editor. We also, had to resolve dispute that arose when changes in the branch conflicted with changes in trunk. The comparator tool made this task easy. Git: Once the changes were made to a branch of the project, we merged these with the master branch. Basically merging in Git required switching to the root branch and executing the git merge branch-name com- mand. The merging process can be either be a simple fast forward merge or a recursive merge. However, this merging process may experience conflicts while merging. In such a case, the merging process fails with the message Automatic merge failure; fix conflicts and then commit the results. Then we were required to open the conflicting file and fix the conflicts. This happened because the same part of a file in two different branches that we were merging were modified uniquely. The conflicts that arose were embedded in the file and could be easily recognized as a diff. After the conflicts were solved we simply ran the git add command. Running the git status tool we saw the conflicts were solved and are ready to be committed to the repository. IV. FINDINGS Both tools provide systematic ways of checking the last updates performed on the local repository by means of a log of changes. Some of the nice features of Subversion is that, it is easy to check in changes and update the local repository without having to check in changes.most teams look for simplicity and effectiveness in versioning tools and subversion is definitely one of the suggested options.branching and Merging is main tasks involved in any standard development project. Even though sub- version give a good UI and a powerful comparator editor tool to achieve this, it makes the job of merging difficult as the tool displays a lot of false positives. Hence, the job of merging requires us to look through the whole set to discover true positives and decide whether to keep it or discard it. Another one of the cons of Subversion is that, if the root repository is not updated periodically, some of the files become stale or out of sync, even if those files are never changed in the root repository. Hence, if we make changes to the file without updating the root repository, the tool repudiate commits with an error.git supports distributed and offline work. This means that we could work on our own local repository seprately of the other team members. Also, git allows us to be offline and not connected to the root repo at all times. This allows us to maintain multiple revisions on the local machine without reflecting those changes onto the root repo. Git was developed with the objective of making branch- ing and combine extremely easy and simple to use. Branching is lightweight because a branch is a small file that points to the most recent commit. On the other hand, Subversion includes replicating the project files into a second directory. This results in time costs and expensive memory in the development process. While performing merging, Git will automatically find the common content between the two branches being merged. This makes @IJCTER-2016, All rights Reserved 453
Fig. 3. statistics that show the popularity of git versus svn merging is Git very easy because in Subversion we need to select the suitable merge base for the two branches. Conflict resolution in Git involves resolving and analyz- ing only the conflicting part of the conflicting files in the two branches. This resolution can be easily performed because Git only reports the most applicable conflicts unlike Subversion, which as stated above, may result in false positive V. CONCLUSION In due course of our evaluation, we find that subversion is versatile and a feature rich tool which user friendly interfaces and tools. This would be an automatic choice for project development teams which work in a closely knit work environment It has a small learning curve and a new user can be brought up to speed very quickly. But on the down side, if the project includes a lot Conflict and Merging in future, it might be difficult to manage them when volume increases. In this case, git has an advantage. Git has a lot of handy features, very effective in exposing merge managing and conflicts multiple parallel versions. Although it has a steep learning curve, it is very versatile and works good in a dynamic project environment. Open Source projects often look towards Git as an effective VCS due to its utility. Most projects these days are moving away from the Centralized approach to the Distributed approach for the same reasons. Based on our findings and experience so far, it is our opinion that Distributed approach outweighs the outdoes and pros the cons of Centralized approach. Hence, we feel that Git is the way to go moving forward. REFERENCES [1] B. Collins-Sussman, The Subversion Project: Building a Better CVS, in Linux Journal, vol. 2002, pp. 3-7, 2002. [2] B. de Alwis and J. Sillito, Why Are Software Projects Moving From Centralized to Decentralized Version Control Systems? in Proceedings of the 2009 [3] ICSE Workshop on Cooperative and Human Aspects on Software Engineering, CHASE 09, pp. 36-39, 2009. [4] J. Estublier, Software Configuration Management: A Roadmap, in Proceedings of the Conference on the Future of Software Engineering, ICSE 00, pp. 279-289, 2000. [5] J. Gray, P. Helland, P. ONeil and D. Shasha, The Dangers of Replication and a Solution, in Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data, SIGMOD 96, pp. 173-182, 1996. [6] K. Hinsen, K. Lufer and G. K. Thiruvathukal, Essential Tools: Version Control Systems, in Computing in Science and Engineering, vol. 11, pp. 84-91, 2009. [7] B. OSullivan, Making Sense of Revision-Control Systems, in Communications of the ACM the Status of the P Versus NP Problem, vol. 52, pp. 56-62, 2009. [8] S. Phillips, J. Sillito and R. Walker, Branching and Merging: An Investigation into Current Version Control Practices, in Proceedings of the 4th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 11, pp. 9-15, 2011. @IJCTER-2016, All rights Reserved 454
[9] J. Plaice and W. W. Wadge, A New Approach to Version Control, in IEEE Transactions on Software Engineering, vol. 19, pp. 268-276, 1993. [10] D. Spinellis, Git, IEEE Software, vol. 29, pp. 100-101, 2012. LINKS: 1. Svn Basics http://openoffice.apache.org/svn- basics.html 2. Git Basics http://git-scm.com/book/en/getting- Started-Git-Basics @IJCTER-2016, All rights Reserved 455