A Rapid Transition from Subversion to Git: Time, Space, Branching,
Merging, Offline Commits & Offline builds and Repository Aspects
Authors: Aggarwal Alok , Singh Vinay , Kumar Narendra 
Published: July 2021

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.