Abstract: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.

LHCb migration from Subversion to Git

MUT: Human-in-the-Loop Unit Test Migration

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

Migrating large codebases to C++ Modules

CERNLIB status

Continuously mining distributed version control systems: an empirical study of how Linux uses Git

Example-Based Automatic Migration of Continuous Integration Systems

Experiences with Automated Build and Test for Geodynamics Simulation Codes

Source Code Archiving to the Rescue of Reproducible Deployment

New simulation software technologies at the LHCb Experiment at CERN

Objectivity Data Migration

HL-LHC Computing Review: Common Tools and Community Software

Choosing between Git and Subversion : How does the choice affect software developers?

GLAS : An open-source easily expandable Git-based Scheduling Architecture for integral Lab Automation

Git4Voc: Git-based Versioning for Collaborative Vocabulary Development

Migration of CMSWEB Cluster at CERN to Kubernetes

Walking the Talk: Adopting and Adapting Sustainable Scientific Software Development processes in a Small Biology Lab

Implementing version control with Git and GitHub as a learning objective in statistics and data science courses

Leveraging DevOps for Scientific Computing

Prototyping a ROOT-based distributed analysis workflow for HL-LHC: the CMS use case

The LHCb software and computing upgrade for Run 3: opportunities and challenges