Fixed #45, citing Nelson.

evolution.html

@@ -41,7 +41,7 @@
 		
 		<p>One of the most common ways of managing change is to <strong>refactor</strong> code. Refactoring helps developers modify the <em>architecture</em> of a program while keeping its behavior the same, enabling them to implement or modify functionality more easily. For example, one of the most common and simple refactorings is to rename a variable (renaming its definition and all of its uses). This doesn't change the architecture of a program at all, but does improve its readability. Other refactors can be more complex. For example, consider adding a new parameter to a function: all calls to that function need to pass that new parameter, which means you need to go through each call and decide on a value to send from that call site. Studies of refactoring in practice have found that refactorings can be big and small, that they don't always preserve the behavior of a program, and that developers perceive them as involving substantial costs and risks (<a href="#kim">Kim et al. 2012</a>).</p>
 		
-		<p>Another fundamental way that developers manage change is <strong>version control</strong> systems. As you know, they help developers track changes to code, allowing them to revert, merge, fork, and clone projects in a way that is traceable and reliable. While today the most popular version control system is Git, there are actually many types. Some are <em>centralized</em>, representing one single ground truth of a project's code, usually stored on a server. Commits to centralized repositories become immediately available to everyone else on a project. Other version control systems are <em>distributed</em>, such as Git, allowing one copy of a repository on every local machine. Commits to these local copies don't automatically go to everyone else; rather, they are pushed to some central copy, from which others can pull updates.</p>
+		<p>Another fundamental way that developers manage change is <strong>version control</strong> systems. As you know, they help developers track changes to code, allowing them to revert, merge, fork, and clone projects in a way that is traceable and reliable. Version control systems also help developers identify merge conflicts, so that they don't accidentally override each others' work (<a href="#nelson">Nelson et al. 2019</a>). While today the most popular version control system is Git, there are actually many types. Some are <em>centralized</em>, representing one single ground truth of a project's code, usually stored on a server. Commits to centralized repositories become immediately available to everyone else on a project. Other version control systems are <em>distributed</em>, such as Git, allowing one copy of a repository on every local machine. Commits to these local copies don't automatically go to everyone else; rather, they are pushed to some central copy, from which others can pull updates.</p>
 		
 		<p>Research comparing centralized and distributed revision control systems mostly reveal tradeoffs rather than a clear winner. Distributed version control, for example, appears to lead to commits that are smaller and more scoped to single changes, since developers can manage their own history of commits to their local repository (<a href="#brindescu">Brindescu et al. 2014</a>). Google uses one big centralized version control repository for all of its projects, however, because it offers one source of truth, simplified dependency management, large-scale refactoring, and flexible team boundaries (<a href="#potvin">Potvin & Levenberg 2016</a>).</p>
 
@@ -60,6 +60,7 @@
 		<p id="brindescu">Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, and Danny Dig. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568322">How do centralized and distributed version control systems impact software changes?</a> In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 322-333.</p>
 		<p id="chen">Chen, L. (2015). <a href="https://doi.org/10.1109/MS.2015.27">Continuous delivery: Huge benefits, but challenges too</a>. IEEE Software, 32(2), 50-54.</p>
 		<p id="kim">Miryung Kim, Thomas Zimmermann, and Nachiappan Nagappan. 2012. <a href="http://dx.doi.org/10.1145/2393596.2393655">A field study of refactoring challenges and benefits</a>. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE '12).</p>
+		<p id="nelson">Nelson, N., Brindescu, C., McKee, S., Sarma, A., & Dig, D. (2019). <a href="https://link.springer.com/article/10.1007/s10664-018-9674-x">The life-cycle of merge conflicts: processes, barriers, and strategies</a>. Empirical Software Engineering, 1-44.</a>
 		<p id="phillips">Shaun Phillips, Thomas Zimmermann, and Christian Bird. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568274">Understanding and improving software build teams</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 735-744.</p>
 		<p id="potvin">Potvin, R., & Levenberg, J. (2016). <a href="">Why Google stores billions of lines of code in a single repository</a>. Communications of the ACM, 59(7), 78-87.</p>
 		<p id="vasilescu">Bogdan Vasilescu, Yue Yu, Huaimin Wang, Premkumar Devanbu, and Vladimir Filkov. 2015. <a href="https://doi.org/10.1145/2786805.2786850">Quality and productivity outcomes relating to continuous integration in GitHub</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 805-816.</p>