Using Dependency Graphs to Support Collaboration Over GitHub:

Transcription

1 Using Dependency Graphs to Support Collaboration Over GitHub: The Neo4j Graph Database Approach Ritu Arora CS & IS Birla Institute of Technology & Science, Pilani, Rajasthan, India Sanjay Goel CSE & IT Jaypee Institute of Information Technology, Noida, Uttar Pradesh, India R.K. Mittal Vice Chancellor K. R. Mangalam University, Gurgaon, Haryana, India Abstract Software Configuration Management Systems capture direct conflicts which arise due to concurrent editing of same shared artifact. However, indirect conflicts, arising due to concurrent editing of related artifacts by collaborative developers, might eventually evade the build process employed by the underlying SCM. Additional collaborative software development tools have been developed, that supplement existing SCM systems, by providing change awareness information about potential indirect conflicts. In this paper, we propose the tool d Collaboration Over GitHub (COG), that provides support for collaborative software development over GitHub and also captures indirect conflicts at finer levels of granularity. For this, COG converts project repositories into dependency graphs which are stored as Neo4j Graph Databases. These graphs store structural and dependency information obtained from codebases and are used for identifying conflicts and affected artifacts. Keywords collaborative software development; configuration management systems; cscw; dependency graphs I. INTRODUCTION Software Configuration Management (SCM) systems are the earliest and one of the most innovative facilitators of Collaborative Software Development (CSD) processes among software development teams. Pioneering SCM systems like GitHub [1], BitBucket [2] etc., are web-based, distributed SCMs, which are being widely used to host project codebases over the Internet. SCM systems provide non-real time support to collaborative developers and are designed to capture direct conflicts that arise due to concurrent editing of same shared artifact. However, indirect conflicts which arise due to concurrent changes to related artifacts are not effectively captured by these SCM systems. Various collaboration tools have been developed to supplement SCM systems, in order to inform collaborative developers about possibilities of potential direct and indirect conflicts [3] [4] in real-time. CSD tools like State Treemap [5], Jazz [6], Moomba [7], FASTDash [8], capture direct conflicts by connecting to individual workspaces of collaborating clients and informing them, in real-time, about conflicting activities on same shared artifact. These tools aim to reduce the occurrences of merge conflicts. Indirect conflicts [3] which are more severe in nature, lead to introduction of syntactic and semantic inconsistencies [4] in project codebases. Semantic inconsistencies can be further classified into those caused due to structural changes and those caused due to behavioral changes [9]. While syntactic and structural semantic inconsistencies are captured during the build process employed by the underlying SCM, behavioral semantic inconsistencies by-pass the build process and would be caught at runtime or testing time or eventually enter the final product. Tools like Palantír [3], Ariadne [10], CASI [11], Conflicts [12], are designed to capture indirect conflicts by monitoring cross-workspace changes, combined with the artifact dependency information to generate conflict information. However, a majority of these tools fail to effectively capture behavioral semantic inconsistencies and also provide change awareness information only at the structural level of the artifacts. In this paper, we propose a novel tool d COG (Collaboration Over GitHub), that enables developers to collaboratively work over projects hosted over GitHub. COG distinguishes itself from existing CSD tools through contribution of the following novel features: 1) provides collaborative software development features over GitHub; 2) captures behavioral semantic inconsistencies which are not effectively captured by existing CSD tools; 3) generate conflict information at finer levels of structural granularity to the level of individual statements. Moreover, COG represents project codebases as dependency graphs which are created as Neo4j Graph Databases [13]. This novel representation of project codebases as dependency graphs is used to detect potential conflicts and identify conflicting artifacts. Designed using client-server architecture, COG connects to collaborating clients and inform about changes in real-time. It supplements Eclipse IDE with collaborative features through collection of plug-ins for programming using Java. The rest of the paper is organized as follows: Section II discusses related CSD tools that capture indirect conflict. Section III provides detail about process flow of COG, along with its architecture. Section IV elaborates on creation of dependency graphs using Neo4j graph databases. Finally, section V details about performance evaluation of COG through simulation using selected open source projects /16/$ IEEE

2 II. EXPLORING RELATED WORK Since COG distinguishes itself from other existing CSD tools through implementation of three novel features, we organize the study of related works accordingly. A. Support for GitHub EGit [14] is an Eclipse Team provider for the Git Version Control System (VCS) consisting of a set of Eclipse plug-ins that provide information about changes in the state of the remote repository with respect to the current local repository of a developer. However, it does not provide information about activities of other collaborative developers and also does not capture indirect conflicts. Crystal [15] provides support for collaborative developers working over Mercurial VCS and proposes to extend the tool for supporting collaboration over Git. However, as per our knowledge, none of the current CSD tool provides collaboration support over GitHub. B. Capturing Indirect Conflicts using Dependency Graphs CSD tools like Ariadne [10], YooHoo [16] and Change Support Environment [17] inform developers about possibilities of potential indirect conflicts. They use different forms of dependency graphs to store and process dependency relationships between various artifacts existing in a project repository. However, these tools do not provide real-time conflict information since they retrieve changes in dependency relationships only when changes by the developers are checked-in into the project codebase. Tools like Palantír [3], CASI [11], Conflicts [12], Plugin over IDEA IntelliJ [18] provide real-time collaboration support but fail to effectively capture behavioral semantic inconsistencies. Palantír [3] addresses indirect conflicts caused due to changes in class signatures only. It also uses dependency graphs (generated using Dependency Finder [19]) to generate dependency information at each collaborating client which helps to divide the processing load to segregated nodes. However, a major drawback of this architecture is that every client needs to maintain an updated copy of the remote repository. CASI [11] provides, in real-time, an emergent design visualization of activities of various developers on the artifacts, down to the method level. Code Synchronizing Intelligence (CSI) [20] identifies semantically related artifacts with the help of information obtained through Abstract Syntax Tree (AST) of Java files and prevents concurrent editing of related program elements, thereby inhibiting real-time editing process. Plugin over IDEA IntelliJ [18], an extension of CSI [20], tracks and informs about changes made to method signature, parameters and return type with the help of the Program Structure Interface (PSI) available with IDEA IntelliJ IDE. However, it does not provide support for capturing statement-level conflicts. Also, the current implementation supports only two developers. Conflicts [12] build over Syde [21] framework, also uses AST of Java files to obtain structural conflict information. It addresses direct and indirect conflicts due to syntactic changes only, between two developers. Crystal [14] and WeCode [22] create a virtually merged system of cross-workspace changes which is compiled and tested (execution of automated test cases). This process would capture majority of inconsistencies, but is bound by the scope of automated test cases. Moreover, for large codebases comprising of hundreds of artifacts with significant number of collaborators, the processing time and efficiency of compiling, executing and testing the entire codebase, with every save action at individual workspace or every commit to the repository, might pose several challenges. III. COG- COLLABORATION OVER GITHUB COG clones remote project repository hosted over GitHub as a directory structure and converts it into a dependency graph. Dependency graphs are an effective way to represent dependency relationship between software artifacts [3] [17]. Each structural element of the project is converted into a node of the dependency graph and stored along with its properties. COG is able to capture behavioral semantic inconsistencies, since it also monitors modifications to each node. Changes to nodes and edges are categorized into cases and listed in tabular form, along with associated rules for identifying and informing related nodes, as shown in Table I. This table is an extended and modified version of the rules proposed in [4]. A. How COG works? At a particular time, the COG server provides support for a single registered project. An administrator can register a project with COG, with the help of the COGEclipseClient or the COGWebClient. Once a project is registered, the server starts the cloning process and creates a clone of the project repository from GitHub and stores it with itself. The cloning step is followed by creation of the project dependency graph which is stored as a Neo4j graph database. These two steps (cloning and graph creation) are repeated at regular intervals. Figure 1 shows the complete process flow of COG. Collaborators can connect to the server and collaborate over the registered project using the COGEclipseClient. Once the server completes the initiation process, the COGEclipseClient residing on the Eclipse IDE of the developer, starts sending activity metadata information to the server. The activity metadata information comprises of the s of the currently open and edited artifacts. For the currently edited artifact, the COGEclipseClient sends the current AST (Abstract Syntax Tree) element in focus and the current line number. This information is processed and stored in MySQL database. The COGEclipseClient sends the content of the current edited file from the individual workspaces, at regular intervals. On receiving the file content, the server creates the dependency graph for this artifact. A comparison algorithm compares the client artifact dependency graph with the project dependency graph and identifies the conflicts. Based on the rules in Table I, the relevant artifacts that would be affected by these changes are identified and their s are attached with the conflict messages. These messages are stored in the MySQL database and are retrieved by the various plug-ins residing with the COGEclipseClient and displayed on the developers IDEs. The COGWebClient uses a web-browser to display the information obtained from MySQL. The AllCollaborators view obtains the list of all the current collaborators while the AllConflicts view displays all the conflict messages stored in

3 the database. The CollaboratorsInfo view displays only the collaborator specific information. TABLE I. RULES FOR IDENTIFYING CLIENTS [4] Case No. of Change Rules for informing nodes Case 1 Addition of a Node (N1) 1) Inform parent of N1 (including transitive sub-nodes of N1) Case 2 Deletion of a Node (N1) 2) Inform all dependencies (including transitive) of parent node of N1 Case 3 Modification of a Node (N1) 1) Inform node N1 (including transitive sub-nodes of N1) 2) Inform all dependencies (including transitive) of node N1 3) Inform parent of node N1 (including transitive sub-nodes of parent of N1) 4) Inform all dependencies (including transitive) of parent of node N1 Case 4 Addition of a connecting edge (ce1) This situation arises due to addition of a node (N1). Hence, same as case 1. Case 5 Deletion of a connecting edge (ce1) This situation arises due to deletion of a node (N1). Hence, same as case 2. Case 6 Modification of a connecting edge (ce1) This case does not exist. Either an ownership relationship exists or does not. Case 7 Case 8 Addition of a dependency edge (de1) from N1 to N2 Deletion of a dependency edge (de1) from N1 to N2 1) Inform node N2 (including transitive sub-nodes of N2) 2) Inform all dependencies (including transitive) of N2 3) Inform parent of node N2 (including transitive sub-nodes of parent of N2) 4) Inform all dependencies (including transitive) of parent of N2 5) Inform node N1 (including transitive sub-nodes of N1) 6) Inform all dependencies (including transitive) of N1 7) Inform parent of node N1 (including transitive sub-nodes of parent of N1) 8) Inform all dependencies (including transitive) of parent of N1 Case 9 Modification of dependency edge (de1) Involves modification of the <<type>> of the relationship. Same as case 7.. or COG Server COGEclipseClient (Administrator) GitHub Repository COGEclipseClient Neo4j DB MySQL Database Fig. 1. B. Architecture of COG COG comprises of three main components. The COG server or the UserCollaboration Engine forms the server component and is hosted on the Apache Tomcat Server. The COGEclipseClient and COGWebClient are the two client COG Process Flow components. The UserCollaboration Engine connects with the project repositories hosted on GitHub, MySQL database and the Neo4j Graph database, and comprises of following subcomponents: GitHubCollaborator Component: Clones the remote project repository at regular intervals.

4 User ActivityContext Analyzer Component: Creates the project dependency graph and the current client artifact graph and generates conflict information by comparing the two graphs. It also processes and stores the activity metadata information from all clients to MySQL. InconsistencyCommunicator Component: Generates conflict information between project dependency graph and client artifact graph. The COGEclipseClient resides on the individual Eclipse IDEs of the clients and comprises of the following: Apache HttpComponents Client Component: Connects the developers workspace with the server and is responsible for sending the required information. ActivityMetaData Provider Component: Collects the clients activity metadata information from the workspace and sends it to the server. Also sends the current file content for generation of artifact graph. IDE DecorationContributor Plugin Component: Responsible for providing presence and change awareness information through collection of plug-ins: - collaboratorinboxdecorator plug-in: Decorates file icons in the project explorer of the Eclipse IDE, based on the number of collaborators working on an artifact. - collaboratorsinfoviewparts plug-in: Provides presence awareness about direct and indirect collaborators working on the same project on GitHub. - collaboratorsconflictsviewparts plug-in: Provides change awareness information by displaying conflict messages retrieved from MySQL database. The COGWebClient is a web-based interface that enables remote users (administrators) to view the current activities of collaborators. It comprises of the following views: AllCollaborators view: Lists down the details of all the collaborators in COG currently working on a project. AllConflicts view: Lists down all the conflict messages generated by COG for all the collaborators. CollaboratorsInfo view: Provides collaborator specific details about current activities and conflict messages. C. Limitations of COG The current implementation of COG does not take care of static attribute and static method invocation. Annotation Declarations and Enumerations declarations in Java files are ignored by the current parser. Inner classes are also not parsed. As a result, the current implementation of COG does not create separate nodes for these identified types in the corresponding dependency graph. E. COG on GitHub The COG project has been open sourced on GitHub. The repository at hosts the code of the UserCollaboration Engine and its components. The repository hosts the code of the COGEclipseClient and the repository at hosts the code of collaboratorinboxdecorator plugin. IV. USING NEO4J GRAPH DATABASE IN COG Transforming project codebases into dependency graphs results in graphs with large number of nodes and edges. Since, Neo4j Graph databases are extremely efficient in managing large sized, highly connected data and executing complex queries, they are a preferred choice. Neo4j Graph databases use Cypher Query Language (CQL) to query these databases. Java libraries are also available to create, store and query graph databases using Java. Graph databases are based on propertygraph model, consisting of connected entities (called nodes) that can have any number of attributes or properties (key-value pairs) associated with them. These nodes are connected to other nodes through directed relationships. A relationship has a type associated with it along with any number of attributes. A. Nodes and Relationship edges in COG In COG, we create seven types of nodes to store the entire project. This is because there exist seven different types of structural program elements in a project. The root node for every project is a PROJECT node which has a and property associated with it. The root node is connected to PACKAGE nodes which represent the packages existing in the project (Table II). TABLE II. node PACKAGE NODE WITH ASSOCIATED PROPERTIES PACKAGE Represents the of the package Represents the complete of the package CLASS and INTERFACE nodes are created for all the classes and interfaces existing in the project. For each class, its,, modifier, imports, packagename, extends and implements are the properties that are stored with the node (Table III). TABLE III. node modifier CLASS NODE WITH ASSOCIATED PROPERTIES CLASS Represents the of the class Represents the complete of the class Represents the modifier of the class D. Extensibility of COG COG can be easily extended to work with any existing SCM, by modifying the GitHubCollaborator Component to clone project repository from the preferred SCM. imports packagename extends implements All packages imported by the class Package to which the class belongs Name of the super class extended List of interface(s) implemented

5 Similarly, METHOD and ATTRIBUTE nodes are used to store methods and attributes declared inside a class. Table IV and V, list the various properties of method and attribute nodes that are stored along with them. The entire body of the method is also stored as a property. The variables declared inside a method are stored as METHOD- ATTRIBUTE nodes, along with the required properties. Each node is connected to its parent node using CONNECTING edges, directed from child node to parent node. DEPENDENCY edges are used to connect nodes based on the type of dependency relationship (Table VI). TABLE IV. node modifier return parameterlist TABLE V. node modifier data initializer TABLE VI METHOD NODE WITH ASSOCIATED PROPERTIES METHOD Represents the of the method Represents the complete of the method Represents the modifier of the method Valid Java data type or any existing class type List of all the incoming parameters Stores the entire body of the method ATTRIBUTE NODE WITH ASSOCIATED PROPERTIES ATTRIBUTE Represents the of the attribute Represents the complete of the attribute Represents the modifier of the attribute Any valid Java data type or class type Initial value assigned DEPENDENCY EDGES AND THEIR TYPES EXTENDS Possible Values of edge from subclass to superclass IMPLEMENTS of the edge from class to interface IMPORTS of the edge from class to class USES of the edge from class to class CALLS of the edge from method to method B. Creation of Project Dependency Graph in COG The cloned project repository obtained from GitHub is stored as a directory structure within the COG server. In order to create the project dependency graph, the COG server walks the entire directory structure and obtains the Abstract Syntax Tree (AST) of each Java file. Project node is created initially and package nodes are created by retrieving package information from the AST of individual classes. AST of each Java file is further traversed to create attribute and method nodes which are connected through connecting edges. Once the entire connected graph is created, a second pass through the AST of each Java file and the created structural project graph, helps to create dependency edges thereby completing the project dependency graph. Dependency edges of type EXTENDS are created between class nodes to represent inheritance relationship, while dependency edges of type IMPLEMENTS are created from class node to an interface node when a class implements an interface. IMPORTS type dependency edges are created between classes when a class imports another class. A USES edge is created from a class node that creates an object of another class (within the class) to the class node whose object is created. USES edge is created between a method node and class node if a method creates an attribute of another class. CALLS edges are created between method nodes when a method of a class invokes a method of another class. No duplicate edges are created. Figure 2 to 4 depict a Java project (MathTutorialProject) and its dependency graph created using Neo4j graph database. Class Closed2DShapes is an abstract class consisting of two abstract methods surfacearea() and perimeter(). Class Square extends Closed2DShapes and implements both the abstract methods. Class ChessBoard creates objects of Square to draw the chess board. A similar process is used to create the dependency graph of the artifact file content received from the client, at regular intervals. The AST of the file is obtained and the connected graph is created. The dependency edges are not stored with the graph but analyzed separately during the comparison phase. C. Comparison of Graphs in COG After creation of the client artifact graph, the comparison algorithm obtains handles to the root nodes of both the graphs for comparison. Information regarding addition of nodes (class, attribute, methods or method-attribute node) is retrieved by comparing all nodes of the client artifact graph with the project dependency graph. Modification of a node occurs due to changes in the properties of a node. Properties associated with each node are compared for both the graphs and changes identified. Changes to individual method bodies are also compared and traced at statement-level. In order to identify deletion of nodes, the artifact sub-graph existing in the server graph, for the class node, is compared to the client artifact graph and missing nodes are identified. For each change, the artifacts that are to be informed are searched in the project dependency graph. These nodes are selected based on the rules given in Table I. Finally, the change message along with the artifact that is to be informed is written to MySQL database. V. PERFORMANCE EVALUATION OF COG USING SIMULATION We evaluated the performance of COG server by measuring the average time taken for creation of client artifact graph, comparison of graphs and generation of conflict information. The time required for this consolidated action is critical, since all the collaborating clients send their current file content to the server at regular intervals, using which the server generates the conflict information. The evaluation is done by using five open-source projects from GitHub as test samples.

6 Fig. 2. Square.java Fig. 3. ChessBoard.java Fig. 4. Project Dependency Graph of the MathTutorialProject created using Neo4j Graph Database (as visulaised in Neo4j Browser) TABLE VII. LIST OF GITHUB PROJECTS USED FOR SIMULATION Project Name Number of Number of Number of Java files Nodes created Edges created hystrix zxing rhino FBReaderJ bigbluebutton Table VII gives the details of these projects, together with the number of nodes and dependency edges created in the project dependency graph of each project. A client simulator generates requests by sending the current artifact s content to the server. These simulations are carried out by running the client and the server on the same machine in order to eliminate the time wasted due to network congestion. Consequently, there exist three important parameters that impact client request execution time: Number of client requests at a particular time (n): This parameter determines the load on the server at a particular time thereby impacting its performance. Numbers of differences between the client file content and the file content available in the project dependency graph (diff): Larger the number of differences, longer would it take to execute the comparison algorithm and greater number of conflict messages will be generated. Radius or the distance of nodes from conflicting node which are to be informed (r): This parameter would increase the execution time, since for higher values of r more nodes are to be informed, leading to generation of greater number of conflict messages.

7 Graph in Figure 5 depicts client request execution time in seconds for n = {1, 2, 4 and 6} for all the five projects. These simulations are executed with incorporations of one difference (diff=1; addition of an attribute) and r = 2. The graph shows that for all the projects the client request execution time increases with the increase in number of clients. However, it remains almost same irrespective of the size of the project. It is important to mention here that a background process at the client s IDE sends these requests to the server at regular intervals. Hence, the time required to process each request does not block or hamper the clients activities within the IDE. bigbluebutton FBReaderJ rhino zxing hystrix One client Two client Four client Six client Fig. 5. Simulation Graph depticting increase in client request execution time with increase in the number of clients. We also simulated client requests for diff = 2 (addition and modification of an attribute), for varied n and r =2. The results revealed an insignificant increase (few nano-seconds) in the execution time. This is so because increasing the diff count does not lead to the execution of larger number of additional code statements. However, it would be important to test the server for larger values of diff, since active collaborators would be developing code that would be increasingly different from the version available in server repository. A similar pattern of insignificant increase in execution time was also observed for increasing values of r. Moreover, it would be extraneous to increase the value of r to higher values, since informing nodes located far from the conflicting node would not be useful. All these simulations were performed using Eclipse IDE (Version: Kepler Release) installed on a Dell Laptop 2.50GHz (Intel Core i5) with 4GB of memory, running Windows 7. VI. CONCLUSION AND FUTURE WORK In this paper, we present the tool COG that aims to provide fine-grained collaboration support to developers working on projects hosted over GitHub. Performance evaluation of COG using simulation ascertains its execution efficiency for largesized projects with significant number of collaborative developers. COG would be useful not only to professional software developers but also for students working on collaborative projects. Empirical evaluation of visualization of presence and change awareness in COG is in progress. Conducting controlled experiments in academic and industrial set-up, to establish COG s effectiveness in supporting collaborative work is next on the agenda. REFERENCES [1] GitHub, Inc. (US), Build software better, together, GitHub, [Online]. Available: [Accessed: May 8, 2016]. [2] Atlassian, Inc.(US), Bitbucket the git solution for professional teams, BitBucket, [Online]. Available: [Accessed: May 31, 2016]. [3] A. Sarma, G. Bortis, and A. Hoek, Towards supporting awareness of indirect conflicts across software configuration management workspaces, in Proceedings of IEEE/ACM international conference on Automated software engineering, ACM, 2007, pp [4] R. Arora and S. Goel, Investigating Syntactic and Semantic Inconsistencies in Collaborative Software Development, in Proceedings of the 2015 Eighth International Conference on Contemporary Computing (IC3), IEEE, 2015, pp [5] P. Molli, H. Skaf-Molli and C. Bouthier, State treemap: an awareness widget for multi-synchronous groupware, in Proceedings of Seventh International Workshop on Groupware, IEEE, 2001, pp [6] L. T. Cheng, S. Hupfer, S. Ross, and J. Patterson, Jazzing up Eclipse with collaborative tools, in Proceedings of the 2003 OOPSLA workshop on eclipse technology exchange, ACM, 2003, pp [7] M. Reeves and J. Zhu, Moomba a collaborative environment for supporting distributed extreme programming in global software development, in Extreme Programming and Agile Processes in Software Engineering, Springer Berlin Heidelberg, 2004, pp [8] J. T. Biehl, M. Czerwinski, G. Smith, and G. G. Robertson, FASTDash: a visual dashboard for fostering awareness in software teams, in Proceedings of the SIGCHI conference on Human factors in computing systems, ACM, 2007, pp [9] R. Arora, S. Goel and R. K. Mittal, Supporting Collaborative Software Development over GitHub, unpublished. [10] C. R. de Souza, S. Quirk, E. Trainer, and D. F. Redmiles, Supporting collaborative software development through the visualization of sociotechnical dependencies, in Proceedings of the 2007 international ACM conference on Supporting group work, ACM, 2007, pp [11] F. Servant, J. A. Jones, and A. van der Hoek, CASI: preventing indirect conflicts through a live visualization, in Proceedings of the 2010 ICSE Workshop on Cooperative and Human Aspects of Software Engineering, ACM, 2010, pp [12] L. Hattori, M. Lanza, and M. D Ambros, A qualitative analysis of preemptive conflict detection, University of Lugano, Tech. Rep 5, 2011 [13] Neo Technology, Inc., Neo4j: The world s leading graph database, Neo4j Graph Database, [Online]. Available: [Accessed: May 22, 2016]. [14] C. Aniszczyk, EGit, [Online]. Available: [Accessed: Jun. 1, 2016]. [15] Y. Brun, R. Holmes, M.D. Ernst, D. Notkin, Crystal: Precise and unobtrusive conflict warnings, in Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, ACM, 2011, pp [16] R. Holmes and R. J. Walker, Customized awareness: recommending relevant external change events, in of 32nd ACM/IEEE International Conference on Software Engineering -Vol 1, ACM, 2010, pp [17] P.T.T.Huyen and K. Ochimizu, A Change Support Model for Distributed Collaborative Work, arxiv preprint arxiv: , [18] S. Levin and A. Yehudai, Alleviating Merge Conflicts with Finegrained Visual Awareness, arxiv preprint arxiv: , [19] Dependency Finder,. [Online]. Available: [Accessed: May 21, 2016]. [20] S. Levin and A. Yehudai, Improving software team collaboration with Synchronized Software Development, arxiv preprint arxiv: , [21] L. Hattori, and M. Lanza, Syde: A tool for collaborative software development, in proceedings of the 32nd International Conference on Software Engineering, vol. 2, IEEE, 2010, pp [22] M.L. Guimarães, A.R. Silva, Improving early detection of software merge conflicts, in Proceedings of the 34th International Conference on Software Engineering, IEEE Press, 2012, pp