Proactive detection of collaboration conflicts

Brun, Yuriy; Holmes, Reid; Ernst, M.; Notkin, David

doi:10.1145/2025113.2025139

Cited by 179 publications

(178 citation statements)

References 36 publications

Supporting

Mentioning

177

Contrasting

Order By: Relevance

“…The difference between local and remote team members is not large and probably not significant 4 ; this may indicate that the likelihood of conflicts depends more directly on other factors than location. More significantly, the majority of responses indicate the work of other teams as the main source of conflicts suggesting that bad practices in the usage of the Git version control system 4 Statistical significance tests do not seem to be applicable: paired tests (such as the Wilcoxon signed-rank test) typically require samples of the same population in different conditions, and unpaired two-sample tests (such as the U test) typically require independent samples. Neither seems justifiably the case in our experiments of local vs. remote: local and remote conditions in each pair are reported by the same person (hence they are likely dependent); the populations of local and of remote are not directly comparable (in our setup, each local group interacts with two remote groups).…”

Section: A Merge Conflicts: Frequency and Originmentioning

confidence: 88%

“…(The average project size was 11'776 lines of code in 68 classes). [19] detect, inspect no no real-time no yes no no no CollabVS [16] detect detect, inspect yes real-time yes yes no no no Crystal [4] detect detect no commit no no yes no no WeCode [15] detect detect no saving no no yes no no CloudStudio [10] prevent, detect, inspect detect, inspect no real-time yes yes yes no yes Collabode [14] no no -no no no no yes no Cloud9 [6] no no -no no no no yes no whether it supports detection of direct conflicts and of indirect conflicts (cf. [26]); whether conflict reports may include false positives; whether conflicts are available in real-time or upon commit; the granularity of the awareness system (line, class, or branch); whether collaborative editing supports shared sessions a la Google Doc and automatic merging of versions.…”

Section: Design Of the Empirical Studymentioning

confidence: 99%

“…These experiments normally involve [16], [10], [26] small (2 or 3 people) teams working on controlled artificial exercises (such as refactoring) that can be carried out in a short programming session. In other cases [4], the experiments used regression data from open-source software repositories to estimate the effectiveness of their conflict detection mechanisms. The present paper's study complements both kinds of experiments by targeting real software development over a considerable time span, beyond the information stored by version control systems, and independent of specific solutions (as they were implemented in the evaluated tools).…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Awareness and Merge Conflicts in Distributed Software Development

Estler

Nordio

Furia

et al. 2014

2014 IEEE 9th International Conference on Global Software Engineering

View full text Add to dashboard Cite

Abstract-Collaborative software development requires programmers to coordinate their work and merge individual contributions into a consistent shared code base. Traditionally, coordination follows a series of "update-modify-commit" cycles, where merge conflicts arise upon committing if individual modifications have diverged and must be explicitly reconciled. Researchers have been suggesting that providing timely awareness information about "who's changing what" may not only help deal with conflicts but, more generally, improve the effectiveness of collaboration.This paper investigates the impact of awareness information in the context of globally distributed software development. Based on an analysis of data from 105 student developers constituting 12 development teams located in different countries, we analyze, among other things: 1) the frequency of merge conflicts and insufficient awareness; 2) the impact of distribution on team awareness; 3) the perceived impact of conflicts and lack of awareness on productivity, motivation, and project punctuality. Our findings include: 1) lack of awareness occurs more frequently than merge conflicts; 2) information about remote team members is missing roughly as often as information about co-located ones; 3) insufficient awareness information affects more negatively programmer's performance than merge conflicts.

show abstract

Section: A Merge Conflicts: Frequency and Originmentioning

confidence: 88%

Section: Design Of the Empirical Studymentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Awareness and Merge Conflicts in Distributed Software Development

Estler

Nordio

Furia

et al. 2014

2014 IEEE 9th International Conference on Global Software Engineering

View full text Add to dashboard Cite

show abstract

“…Crystal [4] does separate background merges of pairs of repositories, comprising that of the developer and that of a co-worker or a central master. The result is one of "textual merge failure", "build failure", "tests failure", or "tests passed" relationship for each repository pair.…”

Section: Related Workmentioning

confidence: 99%

“…In a recent work, Brun et al [4] studied nine of the most active open source projects in GitHub (http://github. com), and concluded that even with modern version control systems, like Git (http://git-scm.com), merge conflicts are "frequent, persistent, and appear not only as overlapping textual edits but also as subsequent build and test failures".…”

Section: Introductionmentioning

confidence: 99%

Improving early detection of software merge conflicts

Guimaraes

Silva

2012

2012 34th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Abstract-Merge conflicts cause software defects which if detected late may require expensive resolution. This is especially true when developers work too long without integrating concurrent changes, which in practice is common as integration generally occurs at check-in. Awareness of others' activities was proposed to help developers detect conflicts earlier. However, it requires developers to detect conflicts by themselves and may overload them with notifications, thus making detection harder.This paper presents a novel solution that continuously merges uncommitted and committed changes to create a background system that is analyzed, compiled, and tested to precisely and accurately detect conflicts on behalf of developers, before check-in. An empirical study confirms that our solution avoids overloading developers and improves early detection of conflicts over existing approaches. Similarly to what happened with continuous compilation, this introduces the case for continuous merging inside the IDE.

show abstract

An empirical study of the effect of file editing patterns on software quality

Zhang

Khomh

Zou

et al. 2014

J Software Evolu Process

View full text Add to dashboard Cite

Developers might follow different file editing patterns when handling change requests. Existing research has warned the community about the potential negative impacts of some file editing patterns on software quality. However, very few studies have provided quantitative evidence to support these claims. In this paper, we propose four metrics to identify four file editing patterns: concurrent editing pattern, parallel editing pattern, extended editing pattern, and interrupted editing pattern. Our empirical study on three open source projects shows that 90% (i.e. 1935 out of 2140) of files exhibit at least one file editing pattern. More specifically (1) files that are edited concurrently by many developers are 1.8 times more likely to experience future bugs than files that are not concurrently edited; (2) files edited in parallel with too many other files by the same developer are 2.9 times more likely to exhibit future bugs than files individually edited; (3) files edited over an extended period of time are 1.9 times more likely to experience future bugs than other files; and (4) files edited with long interruptions have 2.0 times more future bugs than other files. We also observe that the likelihood of future bugs in files experiencing all the four file editing patterns is 3.9 times higher than in files that are never involved in any of the four patterns. We further investigate factors impacting the occurrence of these file editing patterns along three dimensions: the ownership of files, the type of change requests in which the files were involved, and the initial code quality of the files. Results show that a file with a major owner is 0.6 times less likely to exhibit the concurrent editing pattern than files without major owners. Files with bad code quality (e.g. high McCabe's complexity, high coupling between objects, and lack of cohesion) are more likely to experience the four editing patterns. By ensuring a clear ownership and improving code quality, the negative impact of the four patterns could be reduced. Overall, our findings could be used by software development teams to warn developers about risky file editing patterns. Copyright © 2014 John Wiley & Sons, Ltd.

show abstract

Proactive detection of collaboration conflicts

Cited by 179 publications

References 36 publications

Awareness and Merge Conflicts in Distributed Software Development

Awareness and Merge Conflicts in Distributed Software Development

Improving early detection of software merge conflicts

An empirical study of the effect of file editing patterns on software quality

Contact Info

Product

Resources

About