A customisable Change Compiler
Original Publication Date: 2002-Aug-16
Included in the Prior Art Database: 2003-Jun-21
A method of detecting charge in a file is disclosed. Existing techniques commonly address this detection by scanning two files, line by line, and producing a report showing which lines have been changed. Problems associated with this include: Some changes are trivial, but there is no flexibility to suppress these changes from being fixed The change detection has no concept of importance or relevance The changes detected are constant
A customisable Change Compiler
A method of detecting charge in a file is disclosed. Existing techniques commonly address this detection by scanning two files, line by line, and producing a report showing which lines have been changed. Problems associated with this include:
Some changes are trivial, but there is no flexibility to suppress these changes from being fixed
The change detection has no concept of importance or relevance
The changes detected are constant
Changes relevant to one user may not be of interest to another
Moving chunks of text between files is difficult to detect.
Currently change detection is very mechanical. There is no concept of relevance of a change or what sort of change detection is desired by the user. The techniques discussed in this document address the area of intelligent change detection. A 'Change Compiler' introduces new techniques in order to provide change detection based upon intelligence.
A Change Compiler can be used to provide information on changes based on what has changed in what sort of file to produce specific change information. To illustrate the concepts, consider files (where _ is a space and ! indicates a comment) containing these lines of code:
A = '__A___'
B = '___A__'
C = '_!AB__'
D = '__!AB_'
E = '__!ABC'
F = '__A_B_' (Example)
In the case of the prior art, a comparison between A & B will flag up the difference and similarly, for C & D. However, a more intelligent approach, as described in this submission, will note that the only difference between A & B is that of alignment. In the case of files A & B being source code or text, this alignment change may not be particularly relevant. Consequently, this new technique judges this change as being of low importance and so may not be of interest to the user. However, if there are many such alignments adjacent to each other, this may indicate a significant change and so the individual line may be of more interest. Also, however, a group of lines which have an alignment change may not be of interest because a change to a previous line may be the significant change. The concept of a change to a particular line also has an associated impact on other nearby (or adjacent) lines. This document shows how such changes effect one another to produce a tailored change-set based on the needs of the user.
Now consider the comparison of C & D. This is another alignment change, but in this case to a comment. This is deemed to be less relevant than an alignment change
to a code line. The Change Compiler would (normally) consider this change not to be of any interest; however, this function can be fine tuned by users. Further, consider the comparison of D & E. In this case, a comment line has changed. This will not be of any interest to anyone looking for a code change. Consequently, this change will be treated as being of low relevance by the Change Compiler. However, for a designer running the Change Compiler, this comment may be of sl...