Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A real-time conflict resolution mechanism in collaborative programming solution

IP.com Disclosure Number: IPCOM000201679D
Publication Date: 2010-Nov-18
Document File: 6 page(s) / 134K

Publishing Venue

The IP.com Prior Art Database


This article describes an solution where developers can programming collaboratively in the IDE. The programming conflict can be auto-detected and resolved in a real-time manner. A mechanism built upon operation transformation and enhanced for the programming environment will be introduced to handle collaboration activities during programming.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 01 of 6

A real-

      , collaborative programming is very popular among software development. As software requirements become more complex, it is common to have more than one developer working on the design and implementation of one module or software collaboratively. In the solution of supporting collaboration in programming, developers working on the same module usually modify the source code separately on their local environment, and then deliver the changes to a centralized repository for integration. However, modifications at the same time over the same pieces of source code by different people cause change conflicts.

Different use scenarios are designed in different programming environment to support collaboration. The similar structure is that each developer will have his/her own development environment, connected to one centralized source control system for revision control. The differences between the revision control mechanism cause differences in use scenarios.

One kind of solution to resolve revision conflict in collaborative programming is to obtain read-writelock in the change management system. In this type of environment, when one developer wants to make any modifications to any source code, he/shewill check out the file. A lock will be added to this file to prevent others' changes. During the file is locked, the developer can make changes to the file on his local side, others can only read the file. When the modification is done, the developer will check in the file and release the lock. Then other developers can continue modify the files as needed. The typical environments are solutions using ClearCase and CMVC for their change management and version control. This kind of solution avoided conflicting changes in source code. But because no two people can work on one same pieces of code in parallel, the development efficiency is greatly impacted. And people are easily to find out who is locking the file for changes.

Another kind of solution which more popularly used is more like a "Copy-Modify-Merge" scenario. This solution gives up the lock mechanism and allows developers to work the same pieces in an isolation form. When a developer wants to make any changes, he starts to work with the most updated copy of file on his local side. Once the developer finishes changes and wants to commit his code to the repository, the change management system will compare the local file with the one in the repository. If any conflicts were found, the developer will be asked to merge the different versions of files manually. The representers are systems using CVS and SVN as their change control and version management system. This kind of solution allows concurrent changes over same pieces of source code by different people, making development by multi people more convenient. However, there's no good solution to resolve conflicts. Before committing the file, a developer wouldn't know who were making changes to the same file at the same time. When...