1

“Transition from CVCS to DVCS: A Case Study on Reasons, Barriers, and Outcomes”

Course Title: Mining Software Repositories Course Code: COMP5900/CSI5140 Professor: Dr. Olga Baysal Presented by: Iman Eshraghi Date: Nov. 10th, 2015

Kıvanç Muşlu University of Washington Seattle, WA, USA

ICSE 2014 Proceedings of the 36th International Conference on Software Engineering

Christian Bird, Nachiappan Nagappan Microsoft Research Redmond, WA, USA

Jacek Czerwonka Microsoft Redmond, WA, USA

Contents •  Introduction •  Contributions •  History of VCS / SCM •  CVCS vs. DVCS •  Definitions •  Methodology •  Transition

–  Reasons, Barriers, outcomes •  Results •  Conclusion •  Reference •  Questions

2

Introduction CVCSs and DVCSs have been studied extensively… however, … there has been little research on the transition across these systems!

3

Introduction This paper captures the Transition

•  Reasons •  Barriers •  Outcomes

-> Interviews (10 developers) -> Survey (70 developers)

4

Contributions

•  A qualitative study with professional developers transitioning from a CVCS to a DVCS

•  Identification of the key concepts for transition

•  In-depth discussion of the DVCS features that are favored by the developers

5

History of VCS / SCM •  Source Code Control System (SCCS)

– 1972, closed source •  Revision Control System (RCS)

– 1982, open source •  Concurrent Version System (CVS)

– 1986-1990, open source •  Apache Subversion (SVN)

– 2000, open source •  Git ! [Distributed]

– 2005, open source 6

DEFINITIONS

•  repository •  check-out (clone) •  check-in (commit) •  conflict •  merge •  branch •  …

7

DEFINITIONS

•  bridge •  transition •  …

8

CVCS vs. DVCS

9

CVCS vs. DVCS (Pros & Cons)

10

•  performing actions other than pushing and pulling change sets is extremely fast

•  no single point of failure

•  scales well •  security (all data stored in

a secured datacenter) •  easier learning curve

METHODOLOGY

11

Findings

12

Transition Reasons TRANSITION REASONS include the ability to:

•  work offline •  work incrementally •  context switch efficiently •  do exploratory coding efficiently

13

Transition Reasons I.  The ability to work offline: The majority of the survey participants (56% vs. 34%) agree with this observation.

II.  The ability to work incrementally: 97% of the survey participants support this observation by favoring small, frequent commits to one large check-in. CVCSs do not support commits.

14

Transition Reasons III.  The ability to context switch efficiently:

All developers we interviewed focus on the fact that CVCSs make it very difficult to work on multiple tasks simultaneously.

76% of the survey participants agree that CVCSs they use do not provide efficient ways to context switch.

V.  The ability to do exploratory coding efficiently: Half of the developers interviewed, mentioned that CVCSs limit their ability to do exploratory coding.

15

Transition Barriers TRANSITION Barriers include :

•  Learning Curve •  Incomplete Integration •  Scaling

16

Transition Barriers

17

1.  Learning Curve

I.  Centralized vs. Decentralized model II.  Advanced DVCS concepts III.  Conflicting terminology

Transition Barriers

18

2.  Incomplete Integration

I.  Incomplete bridge implementation II.  Missing tooling around B/DVCS

Transition Barriers

19

3.  Scaling

I.  Checked-in large binaries II.  Composite products III.  Long development history

TRANSITION OUTCOMES

20

1.  Reality Meets Expectations I.  Ability to work offline:

95% of the survey participants agree that B/DVCSs let them work offline.

TRANSITION OUTCOMES

21

1.  Reality Meets Expectations II.  Incremental workflow:

97% of the survey participants agree that using B/DVCSs let them work incrementally though commits. Commits act as checkpoints; the developer can revert back to a recent version if some change causes a problem. The ability to create checkpoints makes debugging easier.

Transition Outcomes

22

1.  Reality Meets Expectations III.  Fast and easy context switches:

98% of the survey participants agree that lightweight branches in B/DVCSs let them context switch efficiently.

Transition Outcomes

23

1.  Reality Meets Expectations IV.  Fast and easy exploratory coding:

DVCS branches encourage the developers to try out difficult and complex tasks that might not ship immediately without the fear of failure. A developer confirms this observation.

Transition Outcomes

24

2.  Perception for Productivity

I.  Code volume II.  Implementation speed III.  Code velocity (transit time) IV.  Code quality

Other Result

25

Threats To Validity

26

" Internal validity

" External validity

Conclusion •  An attempt to understand the transition costs and

benefits to a DVCS in a large company

•  Identifies ability to work offline and incrementally, and managing multiple contexts efficiently as the major transition expectations

•  Provides some guidelines for the developers, teams, and managers who consider transitioning

27

Reference •  Kıvanç Muşlu, Christian Bird, Nachiappan Nagappan, and Jacek

Czerwonka. 2014. Transition from centralized to decentralized version control systems: a case study on reasons, barriers, and outcomes. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 334-344

28

Question

29

Questions Question 1:

•  What other reasons or barriers can you think of which involves in motivating or hindering such transition process for a typical software firm?

30

Questions Question 2:

•  Considering the importance of applying a VCS in a collaborative (software) project, do you think it should be considered as a full course topic in the educational institutions?

31

Questions Question 2:

•  Should VCSs only be used by software companies?

32