-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathIntroduction.tex
81 lines (65 loc) · 8.13 KB
/
Introduction.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
%!TEX root = main.tex
\section{Introduction}\label{introduction}
Collaborative development is essential for the success of large projects~\cite{hattori2010syde}, and is enabled by version control systems.
In Git, and other version control systems, developers work on their changes in isolation; periodically synchronizing them by merging with the main line of development.
This can be problematic, because developers can concurrently change the same code, without being aware of each others' changes.
These overlapping changes become evident when they try to merge their work into the main line, and encounter a \emph{merge conflict.}
In the majority of cases, the merges succeed.
However, research has shown~\cite{cassandra,Brun2011} that in open source projects, merge conflicts occur in approximately 19\% of all merges.
Resolving merge conflicts is nontrivial, especially when the changes diverge significantly~\cite{Brun2011}.
The resolution process can be tedious and can cause delays as developers figure out how to approach and resolve conflicts~\cite{cassandra}.
Poorly-performed merge conflict resolutions have been known to cause integration errors~\cite{bird-branches-conflict}, workflow disruptions, and jeopardize project efficiency and introduce delays~\cite{estler2014awareness}.
Developers are aware of the problems posed by merge conflict resolutions.
They follow different informal processes to avoid encountering, or having to resolve conflicts; e.g. sending out emails to the rest of the team~\cite{deSouza2003breaking}, performing partial commits, or racing to finish changes~\cite{cataldo2008distributed_dev}.
Unfortunately, these practices come with their own problems, and can make the resolution of a merge conflict even harder~\cite{Brun2011}.
Past work examined different mechanisms for proactive merge conflict detection, including Crystal for preemptive merging~\cite{Brun2011}, Palant\'{i}r for awareness of parallel changes~\cite{palantir} and WeCode for continuous merging~\cite{Guimaraes}.
\citet{mens2002state} presented a survey of merge conflict resolution techniques examined up to 2002.
\citet{nishimura} used fine-grained edit history to localize potential conflicts.
\citet{apel_semistructured_2011,apel_structured_2012-1} presented an approach for merging code, by taking into consideration the syntactical structure of the code.
\citet{lippe_operation-based_1992} presented Operational Based Merging, and \citet{dig_effective_2008} proposed a refactoring-aware implementation for Java, called MohaldoRef.
Finally, \citet{hunt2002extensible} presented an extensible language-aware merging technique that uses both language structure and semantics for improved results.
However, several key questions remain unanswered:
How do developers approach and manage merge conflicts?
How do developers perceive the difficulty of a merge conflict resolution?
Do the current tools support developers' merge conflict resolution needs?
Without such knowledge, tool builders might be building on wrong assumptions and researchers might miss opportunities for improving the state of the art.
To answer these questions, we talked directly to developers.
This step is crucial to understanding problems in the context in which they occur; which is highlighted by researchers as a pressing concern in software engineering~\cite{fritz2010using, sillito2006questions, ko2007information}.
We interviewed 10 software developers from 7 organizations about their experiences and perceptions of merge conflicts. % in the software development process.
Our participants had a median of 5 years of software development experience, and work on a mix of both small-scale (less than 10 contributors) and large-scale projects (greater than 1000 contributors).
These interviews helped us understand how developers approach and manage merge conflicts, and their unmet needs within their processes and tools.
To triangulate our findings and provide a broader understanding of developers' processes, techniques, tools, barriers, and perceptions of merge conflicts, we deployed two surveys to a larger population of software developers.
The \textit{Barriers Survey} and \textit{Processes Survey} sampled 162 and 102 developers, respectively (264 developers in total).
For both surveys, the majority of our participants had 6 or more years of software development experience, and reported facing merge conflicts a few times a week.
To understand how software developers manage merge conflicts, including the tools used and difficulties experienced, we answer the following research questions:
\begin{itemize}[label=$\bullet$]
\item \textbf{RQ1:} How do software developers become \textbf{aware} of merge conflicts?
\item \textbf{RQ2:} How do software developers \textbf{plan} for merge conflict resolutions?
\item \textbf{RQ3:} How do software developers \textbf{evaluate} merge conflict resolutions?
\item \textbf{RQ4:} What difficulties do software developers experience when managing merge conflicts?
\item \textbf{RQ5:} How well do tools support developer's needs for managing merge conflicts?
\end{itemize}
We found that developers, when initially assessing a merge conflict, rely on the \textit{code complexity of the conflicting lines} and \textit{their own knowledge in the area of the conflict} as the top two factors when estimating the difficulty of a merge conflict resolution.
These concerns cause developers to alter their resolution strategy, and in some cases delay the resolution, which can have negative consequences.
After understanding the merge conflict, developers must resolve the conflict in order to return to normal development.
We found that the key challenges that developers face when resolving conflicts are \textit{understanding the conflicting code,} and having enough meta information about the conflicting code (who made the change, why, and when).
Developers rely heavily on \textit{their knowledge of the conflicting code} when implementing their merge resolutions.
Our findings show that developers perceive that an \textit{increase in conflict complexity} has a greater impact on the resolution difficulty, than an increase in the size of the conflict.
However, development tools lack features that address this dimension.
This could partially be alleviated by focusing on the tool improvements most desired by developers: \textit{better usability, better information filtering,} and \textit{better history exploration.}
%In the context of these findings, we present implications for researchers, tool builders, and practitioners.
%For example, researchers have previously developed merge conflict avoidance and resolution tools that need to be simplified and brought into alignment with the basic merging tools used by software practitioners.
%Tool builders should create merging tools that provide more context-sensitive information about conflicting code, and do so when scaling to more complex merge conflicts.
Overall, we make the following contributions:
\begin{enumerate}
\item We introduce a model of developers' processes for managing merge conflicts, from the point of \textit{awareness} to the \textit{resolution} of a conflict;
\item We discuss proactive and reactive strategies developers use when monitoring for merge conflicts;
\item We provide evidence for the prevalence of deferring a merge conflict resolution, and the knock-on effects of doing so;
\item We provide empirically-derived rankings of factors that developers perceive as increasing the difficulty of a merge conflict resolution;
\item We expose disparities between developers' needs when resolving merge conflicts, and the features provided by development toolsets.
%\item We present actionable implications that researchers, tool builders, and practitioners can build upon.
\end{enumerate}
This article extends the work presented at ICSME 2017~\cite{mckee2017software} through the addition of the first three contributions (see above), and in particular:
(1) by providing a model of developer's processes for managing merge conflicts;
(2) conducting an additional \emph{Processes Survey} for validating our model and examining developers' strategies, and;
(3) extending the results of the previously conducted \emph{Barriers Survey} by further analysis based on our process model.