A Rapid Transition from Subversion to Git: Time, Space, Branching, Merging, Offline Commits & Offline builds and Repository Aspects

Background: Software development is the transition from centralized to decentralized version control systems. This transition is driven by the limited features of centralized version control systems in terms of branching, merging, time, space, offline commits & builds and repository aspects. Transition from Subversion; a centralized version control system, to Git; a decentralized version control system has been focused in a limited way. Objective: In this work transition process from Subversion Version Control System (VCS) to Git VCS has been investigated in terms of time, space, branching, merging and repository aspects from the software developer’s point of view; working individually or in a large team over a large and complex software having a legacy of many decades. Experimentation was conducted in SRLC Software Research Lab, Chicago, USA. Methods: Various scripts have been developed and executed for version control using Git and performed over a few legacy software. Results: Results show that branching in Git and Subversion has a difference of about 39 times, i.e. branching operation of Git is about 39 times faster than Subversion. Merging in the case of Git is trivial and automatic, while Subversion needs a manual process of merging, which is error prone. Using an example of Mozilla with fsfs backend, it is observed that disk space can be saved up to 30 times in Git compared to Subversion. By taking a typical example of a large sized project it is observed that Git requires almost half of the revisions compared to Subversion, further with fsfs backend a project having ten years of history with 240,000 commits needs 240 directories in case of Subversion while Git requires only 2 directories. Using offline commits and offline builds of Git, it is observed that in Git whitespace changes, in contrast to significant business logic changes, can be staged in one commit only. These are not possible in Subversion, which requires a complicated system of diffing to temporary files. It is also observed that Git provides offline commit facility, i.e. in case if for some reason, remote repository is unavailable due to disaster or network failure, then still developers can commit their offline code and execute the offline build. Conclusion: However, no previous study was found that focused on how the choice actually affects software developers and it forms the motivation for the present work. In this work, a list of how the choice between Git and Subversion affects software developers is worked out. Although software developers in many aspects are unaffected by the choice, few interesting findings were achieved. One of the most interesting findings of the proposed work is that software developers seem to publish their code to the main repository more often in Git than in Subversion. It is also found that the majority of the software developers perform at least two commits per push, which means that Git repositories will contain a lot more saved points in history than Subversion repositories.