Collaborative Real Time Coding or How to Avoid the Dreaded Merge

Software engineers who collaborate to develop software in teams often have to manually merge changes they made to a module (e.g. a class), because the change conflicts with one that has just been made by another engineer to the same or another module (e.g. a supplier class). This is due to the fact that engineers edit code separately, and loosely coordinate their work via a source control or a software configuration management system (SCM). This work proposes to eliminate almost all the need to manually merge a recent change, by proposing a Collaborative Real Time Coding approach. In this approach, valid changes to the code are seen by others in real time, but intermediate changes (that cause the code not to compile) result in blocking other engineers from making changes related to the entity (e.g. method) being modified, while allowing them to work on most of the system. The subject of collaborative real time editing systems has been studied for the past 20 years. Research in this field has mostly concentrated on collaborative textual and graphical editing. In this work we address the challenges involved in designing a collaborative real time coding system, as well as present the major differences when compared to collaborative editing of plain text. We then present a prototype plug in for the Eclipse Integrated Development Environment (IDE) that allows for a collaborative coding to take place.Comment: This paper was written on 201

Alleviating Merge Conflicts with Fine-grained Visual Awareness

Merge conflicts created by software team members working on the same code can be costly to resolve, and adversely affect productivity. In this work, we suggest the approach of fine-grained merge conflict awareness, where software team members are notified of potential merge conflicts via graphical decoration of the relevant semantic elements, in near real-time. The novelty of this approach is that it allows software developers to pinpoint the element in conflict, such as a method's body, parameter, return value, and so on, promoting communication about conflicting changes soon after they take place and on a semantic level. We have also conducted a preliminary qualitative evaluation of our approach, the results of which we report in this paper