Browse Prior Art Database

A system and method to predict potential code conflict

IP.com Disclosure Number: IPCOM000244163D
Publication Date: 2015-Nov-18
Document File: 6 page(s) / 236K

Publishing Venue

The IP.com Prior Art Database

Abstract

Code conflict is a existing problem in code management tools. Currently there are two ways to deal with code conflict: Locking code while check out or Provide a auto-merge function on code management tools. These methods either broke the efficientcy of parallel code changes in the project, or cannot guarantee the accuraty of the merge result, sacrifice the programmer's personal efficiency. This disclosure provide a compromise way, which make sure the programmer can still coding parallel in the most of time. Meanwhile, they can choose to serialize the code changes through predict the potential code conflict.

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

Page 01 of 6

A system and method to predict potential code conflict

Code conflict is a existing problem in code management tools. Currently there are two ways to deal with code conflict. 1) Locking code while check out, which actually serialize the code check in process. This way avoid code conflict in advance, but it broke the parallel code changes in the whole project. It is inefficiency. 2) Provide a auto-merge function on code management tools, this will guarantee the parallel code changes and efficiency, but auto-merge function will not resolve all situations. There still cases that cannot be auto-merged, which will take programmer's time to review the code, and merge the code manually. It sacrifices the programmer's personal efficiency.

This disclosure provide a compromise way, which make sure the programmer can still coding parallel in the most of time. Meanwhile, they can choose to serialize the code changes through predict the potential code conflict.

Through adding linkage between work-items and project-files, and checking the In-process work-items' owner count, the potential code conflict is predicted.

If there are more than one owner in the file's related in-process work-items, there is a potential code conflict. There will be a marker beside the file name e.g. build.xml (Author Name 1, Author Name 2)which indicate who are working on this file. Joyce and Mike can communicate if there is a real conflict (cannot be auto-merged), and if yes, they can serialize the code change process.

In Code&Project Management system, code changes always linked to work-items.

Change Set is existing code changes. This disclosure adds a predicted code changes link to work-items, which called Related Code. Currently, when user creates an work-item (task, defect, story, ...), Title, Description, File Against, Parent ... are input by user. Those are basic information of a work-item. Whenever user check in...