Managing changes to one or more files via linked mapping records

A computer program product includes program code for managing changes to one or more files via a link is associated with the changes that result in an updated version of the one or more files. A changed section determiner determines which sections associated with the one or more files have changed. The changed section operator further determines metadata regarding the nature of the changes to the sections. Based on the metadata a metrics generator generates a first weight associated with each of the changed sections. A mapping record generator generates a mapping record for each of the changed sections. A first mapping record comprises data associated with the first weight. The first mapping record is associated with a particular version of the one or more files and is linked to mapping records associated with other changed sections using the link.

BACKGROUND

1. Technical Field

The present disclosure relates to managing changes to one or more files. In particular, the present disclosure relates to managing changes to one or more files using a link associated with changes and creating an updated version of the one or more files based on the changes.

2. Description of the Prior Art

Presently, it is difficult to identify parts of a file that need to be changed when an associated file is changed. For example, it is difficult to identify which parts of documentation for a product require updating when associated code for the product is changed, or vice versa. This can result in, for example, the documentation being out of date (e.g., because the documentation has not been updated to reflect changes in the code) or cause documentation associated with the code to be present in multiple locations and not be consistently updated in each of the locations.

AtFIG. 1, there is depicted a block diagram of a prior art solution. As shown, the system comprises system100having client computer105operable to interact with server computer107. The server computer107comprises coordinator110and version control system115having access to first data store125for storing one or more files. In the example herein, the files comprise code and associated documentation. The system further comprises linking system120having access to second data store130for storing one or more links.

AtFIG. 2there is provided a flow diagram of the process according to the prior art. At step200, a user uses client computer105to make changes to code and to documentation and “commits” the changes to a change management system (e.g., server computer107). Coordinator110receives the changes from client computer105and coordinates version control system115to access the files in first data store125and to update the relevant files (step205). At step210, Coordinator110coordinates linking system120to create a link. The links are created between one or more code files and one or more documentation files. Coordinator110coordinates linking system120to create a link between the code file(s) that was changed by the user and the documentation file(s) that was changed by the user. Linking system120links the files by use of a timestamp, wherein a code file and a documentation file are linked if they are committed at the same time. Alternatively, linking system120may link the files if changes associated with the file are committed under the same change item (which has an identifier) wherein a change item can be used to group changes associated with a logical unit of work. Linking system120stores the link in second data store130.

The solution provided by the prior art, as described inFIGS. 1-2, is disadvantageous since this solution is coarse grained. For example, in the prior art links can only be created based on an exact timestamp or a change item. Further, it is not possible to easily identify which sections of the documentation relate to which sections of code.

SUMMARY

There is provided an apparatus and a computer program product for managing changes to one or more files via a link associated with the changes that result in an updated version of the one or more files. In a first aspect of the present disclosure there is an apparatus comprising a changed section determiner that determines which sections associated with the one or more files have changed and determines metadata regarding the nature of the changes to the sections. The apparatus may further comprise a metrics generator that uses the metadata to generate a first weight associated with each of the changed sections and a mapping record generator that generates a mapping record for each of the changed sections. The first mapping record comprises data associated with the first weight, is associated with a particular version of the one or more files, and is linked to mapping records associated with other changed sections using the link.

According to a second aspect, there is provided a computer program product for managing changes to one or more files via a link associated with the changes that result in an updated version of the one or more files. The computer program product comprises code for determining which sections associated with the one or more files have changed, determining metadata regarding the nature of the changes to the sections, using the metadata to generate a first weight associated with each of the changed sections, and generating a mapping record for each of the changed sections. The first mapping record further comprises data associated with the first weight, is associated with a particular version of the one or more files, and is linked to mapping records associated with other changed sections using the link.

By creating and maintaining a link between e.g., code file(s) and documentation file(s), the present disclosure creates a dependency such that when planning any code changes, sections that require updating in the documentation can easily be found and vice versa. This allows a number of further advantages, such as an improvement in the quality of documentation created, a reduction in cost of updating documentation due to the relevant documentation requiring changes being identified automatically and without the need to rely upon a specialist with experience in the particular area, and an improved ability to plan product changes and determine the cost of such changes.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now toFIG. 3, there is depicted a block diagram of a system for generating and maintaining links according to a preferred embodiment of the present disclosure.FIG. 3illustrates system300comprising client computer305that is operable to interact with server computer310. Server computer310comprises coordinator315and version control system320having access to third data store325for storing one or more files. In the example described herein, the files comprise code and associated documentation. However, the files can comprise any number of artefacts (e.g., code only; documentation only). Server computer310also comprises linking system330having access to fourth data store335for storing one or more links. Server computer310further comprises changed section determiner340for accessing third data store325, fourth data store335, metrics generator345, and mapping record generator350. Mapping record generator350accesses fifth data store355to store one or more mapping records.

AtFIG. 4there is provided a flow diagram illustrating a process for generating links according to the preferred embodiment. A user uses client computer305to make changes to at least one of: a code and a documentation. In the example herein, the changes are associated with a change item which has an identifier, such as a work item that is associated with a changed function in the code (e.g., a work item6000is associated with adding a new function to enable secure access to a web site and a work item5000is associated with adding a new method to an interface) or an entry in a change set which is typically smaller in scale than a work item. A work item may comprise a plurality of change sets. In the example herein, the change item comprises a work item.

At step400, in the example herein, client computer305is used to send data comprising a changed code file (having an identifier), a changed documentation file (having an identifier or alternatively file identifiers associated with the changed files, and the changed information and/or associated offset data) and an associated work item identifier to server computer310. In the example herein, coordinator315receives the data and passes the data to version control system320.

Version control system320uses file identifiers associated with the changed code file and the changed documentation file in order to access the files in third data store325and find server-held versions of the files. Version control system320compares the changed code file and the changed documentation file with the server-held versions in order to determine the changes that the user has made (e.g., using a diff tool).

Thereafter, at step405, version control system320updates the server-held versions in third data store325and stores the changed files as new versions. Preferably, the original server-held versions of the files are also maintained. It should be understood that determining the changes and updating the files can be carried out in a number of ways. At step410, coordinator315invokes linking system330to create a link between the code file that was changed by the user and the documentation file that was changed by the user under the work item. Note that a link is associated with changes that result in updated versions of associated files. Linking system330stores the link (e.g., using a link identifier) in fourth data store335.

At step415, changed section determiner340is operable to access third data store325and fourth data store335in order to determine which sections of the code file(s) and the documentation file(s) were changed by the user. Changed section determiner340is also operable to determine further data regarding the changes (e.g., size of the changes, complexity of the changes). In one embodiment the further data is metadata. At step420, metrics generator345generates weightings associated with the link between the code file and the documentation file that have been changed under the work item. That is, in more detail, metrics generator345generates a weighting associated with each changed section of the code file(s) and the documentation file(s). Metrics generator345communicates with changed section determiner340in order to obtain further data associated with the code changes (e.g., size, complexity, and code coverage analysis) and to obtain further data associated with the documentation changes (e.g., size, complexity, change in values, and nature of changes such as a change in tense). Metrics generator345uses the further data in order to create the weighting.

At step425, mapping record generator350generates a set of mapping records associated with the link. The set of mapping records associated with the link comprises the same identifier. Mapping record generator350generates a mapping record for each changed section comprising a weighting associated with the changed section, an identifier, and a time stamp. Mapping record generator350stores mapping records in fifth data store355. Advantageously, a set of mapping records associate a section(s) of code that is changed and a section(s) of documentation that is changed under the same work item, wherein the changes results in a new version of associated files.

A worked example ofFIG. 4will now be described. At step400, in the example herein, the user uses client computer305to send data comprising a changed code file, a changed documentation file, and an associated work item identifier (e.g., 4000) to server computer310. Example changes to the code file and the documentation file are shown below:Changes_1Code file version (ID 1234)—line3-10Documentation file version (ID 5678)—line60-80

Coordinator315receives the data and passes the data to version control system320. Version control system320uses file identifiers (e.g., “1234” and “5678”) in order to find server-held versions of the files and further determines that a section comprising lines3-10have changed in the code file and that a section comprising lines60-80have changed in the documentation file. It should be understood that changes may not necessarily be made to every line of a section (e.g., if a user has made changes to lines3to5and lines8-10of a file, lines3-10may be treated as a single changed section).

Thereafter, at step405, version control system320updates the server-held versions in third data store325. In the example herein, the original versions (termed herein, version1) of the files and the updated versions (termed herein, version2) of the files are stored in third data store325.

At step410, coordinator315invokes linking system330to create a link between the code file that was changed by the user and the documentation file that was changed by the user under the work item. Note that a link is associated with changes that result in an updated version of a file. Linking system330stores the link (e.g., using a link identifier) in fourth data store335. An example of a link is shown below:Link_1Link ID=4321 (Code file version=1234; Documentation file version=5678; Work_item=4000)

At step415, changed section determiner340accesses third data store325and fourth data store335and determines that a section comprising lines3-10have changed in the code file and that a section comprising lines60-80have changed in the documentation file. Changed section determiner340also determines further data regarding the changes. In one example, further data comprises a size of the change in relation to a total size of a file (e.g., by dividing the number of lines changed by the total number of lines in the file).

In another example, further data comprising complexity of a change is estimated. In one example, a programming language associated with a code file is identified and thereafter, e.g., for complied languages such as Java (Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates, a compiler is executed in order to obtain a parse tree for an updated version of the code file and a preceding version of the code file. Nodes of each parse tree are iterated in order to determine differences. For example, a number of nodes in the new tree that are not identical to ones in the previous tree could be counted. In another embodiment, a cyclomatic complexity of each of an updated version of the code file and a preceding version of the code file is calculated.

At step420, metrics generator345generates weightings associated with the link (Link_1) between the code file and the documentation file that have been changed under the work item. Metrics generator345communicates with changed section determiner340in order to further obtain data associated with the code changes and further data associated with the documentation changes in order to create a weighting. It should be understood that any amount of further data regarding the changes can be taken into account in order to generate a weight and any number of weighting schemes can be used.

In the example herein, weights for each changed section associated with the link are generated using further data associated with size as shown below, wherein in the example, a greater weight (e.g., 20) is given to a change having a larger size:Weights_1Code file version (ID 1234)—java line3-10; weight=7Documentation file version (ID 5678)—java line60-80; weight=20

The weight is a relative measure of how important a changed section is. For example, if a changed section has a higher weight, a user would want to be alerted to it in preference to a changed section having a lower weight.

At step425, mapping record generator350generates one or more mapping records associated with the link, as provided by examples shown below:Mapping record ID=123Code file version ID=1234Region start offset=3Region end offset=10Timestamp=12/4/12 07:00Weight=7Mapping record ID=123Documentation file version ID=5678Region start offset=60Region end offset=80Timestamp=12/4/12 07:05Weight=20

Advantageously, a set of mapping records is associated with a changed section(s) to code and a changed section(s) to documentation associated with the same work item and associated with a link to a particular version of associated files. If changes associated with a link are received and if such changes have associated lines that overlap (wherein the overlap can have a preferred size), these changes can be merged for the purposes of detailing in a mapping record. Alternatively, mapping records can be created for each of the overlapping changes. In the example herein, there are further changes (step400) associated with the same work item (ID=4000).

Example changes to the code file and the documentation file are shown below. In particular, the file versions have different identifiers from those denoted in Changes_1as the further changes being made result in a different version of the files:Changes_2Code file version (ID 123456)—line3-8Documentation file version (ID 5678910)—line20-23

As above, at step405, version control system320updates the server-held versions in third data store325. In the example herein, version2and the updated versions (termed herein, version3) of the files are stored in third data store325. Further, version1is also maintained.

At step410, coordinator315invokes linking system330to create a second link which is stored by linking system330in fourth data store335. An example of a link is shown below—note that as Changes_2results in updated versions of the associated files, Link_2has a different Link ID from those denoted in Link_1:Link_2Link ID=4444 (Code file version=123456; Documentation file version=5678910; Work item=4000)

At step415, changed section determiner340accesses third data store325and fourth data store335and determines that lines3-8have changed in the code file and lines20-23have changed in the documentation file. Changed section determiner340also determines further data regarding size of the changes.

At step420, metrics generator345generates weightings associated with the link (Link_2) by using the further data regarding the changes determined by changed section determiner340.

In the example herein, weights for each changed section associated with the link are generated using further data associated with size as shown below, wherein in the example, a greater weight (e.g., 5) is given to a change having a larger size:Weights_2Code file version (ID 123456)—line3-8; weight=5Documentation file version (ID 5678910)—line20-23; weight=3

At step425, mapping record generator350is operable to generate one or more mapping records associated with the link—note that the ID (e.g., 1234) of the mapping records associated with Changes_2is different from the ID (e.g., 123) of the mapping records associated with Changes_1to reflect the different resulting versions of the associated files—examples are shown below:Mapping record ID=1234Code file ID=123456Region start offset=3Region end offset=8Timestamp=12/4/12 09:00Weight=5Mapping record ID=1234Documentation file=ID 5678910Region start offset=20Region end offset=23Timestamp=12/4/12 09:05Weight=3

From the above examples, it can be seen that when changes are made to a code file and to a documentation file and result in updated versions of the files, such changes can be linked under a set of mapping records. This allows a user to have an overview of the impact on one file of changes made to another file. Further, each changed section is advantageously weighted such that a user can understand the relative importance/significance of the changed section on each of the impacted sections and focus his/her attention appropriately, thus ignoring a majority of irrelevant results. Further still, such weightings can be used in another process of the preferred embodiment for analyzing links as will be detailed below. In one embodiment, a mapping record is linked to other mapping records associated with changed sections via a link.

In an example, when a user activates a preferred implementation in a code file, the preferred implementation generates a call hierarchy using, for example, static analysis, code coverage to scan through each of the changes to the code file found, checking for links (such as within a documentation file). The preferred implementation renders a tree for the hierarchy in conjunction with the further data regarding the changes and the tree is augmented with the documentation file as a child node of a parent node representing the code file. Preferably, if the user activates the child node, the documentation file is opened in an appropriate editor.

A system and process for analyzing links will now be described. When changing code (for example) a developer can carry out a manual impact analysis on the code in order to find out which other artefacts may be affected by the code changes. If another artefact (e.g., an associated documentation) is required to be changed, a developer may not necessarily remember to update the documents or indeed know which parts of the documentation require updating. Advantageously, the system and process for analyzing links according to the preferred embodiment aids with the problem above in that, in response to making a change to a file, a user is able to review sections of the file and/or sections of other files which may require updating also.

With reference toFIG. 5, there is provided a more detailed block diagram of a system for analyzing links according to the preferred embodiment. As illustrated there is client computer305which comprises dependency display generator510. Further functions of the client computer305depicted inFIG. 3have been omitted inFIG. 5for clarity. Server computer310comprises metrics generator345and resolver515operable to access fifth data store355for storing one or more mapping records. Further functions of the server computer310depicted inFIG. 3have been omitted inFIG. 5for clarity.

With respect now toFIG. 6there is illustrated a flow diagram showing the operational steps involved in a process for analyzing links according to the preferred embodiment. At step600, a user uses client computer305to make changes (termed herein, proposed changes) to code only. The user sends data comprising the changes and the associated work item identifier to server computer310. Example changes to the code file are shown below:Changes_3(1) Code file version (ID trunk/Test/src/com/test/Test.java)—line48-51(2) Code file version (ID trunk/Test/src/com/test/Types.java)—line7-9(3) Code file version (ID trunk/Test/src/com/test/Types.java)—line17-20

Additionally, the first proposed change is shown in greater detail inFIG. 7. With respect toFIG. 7, there is illustrated a block diagram showing the first proposed change provided above, according to the preferred embodiment. As provided inFIG. 7there is illustrated proximate change mapping record1700and region record1705.

The second and third proposed changes are shown in greater detail inFIG. 8. With respect toFIG. 8, there is illustrated a block diagram showing the first second and third proposed changes provided above, according to the preferred embodiment. AtFIG. 8there is illustrated proposed change2800and proximate change mapping record2805. Also illustrated inFIG. 8is third proposed change810.

Returning now toFIG. 6, version control system320updates the server-held versions in the third data store325. Coordinator315invokes the linking system330to create a link between the changed sections of the code file (further details of the link are omitted herein for clarity) which is stored by linking system330in fourth data store335. Changed section determiner340accesses third data store325and fourth data store335in order to determine which sections have changes and determine further data regarding the changes.

Metrics generator345optionally generates weightings associated with the link by using the further data regarding the changes determined by changed section determiner340and mapping record generator350. Metrics generator345is further operable to generate mapping records associated with the link. If weightings are not generated, a default value of one (1) is used in the algorithms that follow.

A greater weight is given to more significant changes. A greater weight may be assigned based on, for example, a size or complexity of a change. In another embodiment, a greater weight can be assigned based on a more recent change. Examples of the mapping records are shown below:Proposed change mapping record1Mapping record ID=ABCCode file ID=trunk/Test/src/com/test/Test.javaRegion start offset=48Region end offset=51Timestamp=20/4/12 09:00Weight=30Proposed change mapping record 2Mapping record ID=ABCCode file ID=trunk/Test/src/com/test/Types.javaRegion start offset=7Region end offset=9Timestamp=20/4/12 10:00Weight=1Proposed Change mapping record1Mapping record ID=ABCCode file ID=trunk/Test/src/com/test/Types.javaRegion start offset=17Region end offset=20Timestamp=20/4/12 11:30Weight=5

Alternatively, the user can, for example, select areas of the code to which he/she wishes to make proposed changes. Mapping record generator350then uses the selections to generate dummy proposed change mapping records each having a default weight of 1. Alternatively, the user can call by activating an element associated with a code file by selecting a method from a call hierarchy and requesting a list of callers associated with the selected method. In addition to returning the callers, mapping record generator350generates one or dummy proposed change mapping records each having a default weight of 1 associated with an area of code associated with the element.

At step605, resolver515accesses fifth data store355and runs one or more queries in order to retrieve mapping records associated with previously made changes that are proximate to the proposed changes. In one example, resolver515runs one or more queries to obtain mapping records associated with changes that are located in a section that is within 50% of the size of the proposed change. For example, a proposed change from lines20-30would match proximate changes comprising lines15-35and lines25-26but not lines20-22.

In a first query associated with the first proposed change comprising “select all mapping records where file id=trunk/Test/src/com/test/Test.java; start offset is in the range46-50; end offset is in the range49-55”, the following mapping record is returned:Proximate change mapping record1Mapping record ID=XYZCode file ID=trunk/Test/src/com/test/Test.javaRegion start offset=46Region end offset=52Timestamp=18/4/12 10:00Weight=43

In a second query associated with the second proposed change comprising “select all mapping records where file id=trunk/Test/src/com/test/Types.java; start offset is in the range5-9; end offset is in the range7-11”, the following mapping record is returned:Proximate change mapping record2Mapping record ID=XYZCode file ID=trunk/Test/src/com/test/Types.javaRegion start offset=8Region end offset=9Timestamp=17/4/12 11:30Weight=13

Fifth data store355also comprises the following record having the same mapping record ID as the two mapping records above:Change mapping record1Mapping record ID=XYZDocument file ID=file id: trunk/Docs/src/Installation.xmlRegion start offset=28Region end offset=48Timestamp=17/4/12 12:00Weight=34

In a third query comprising “select all mapping records where file id=trunk/Test/src/com/test/Types.java” where the start offset is in the range15-19and the end offset is in the range18-22, no mapping records (including change mapping record1) are returned.

Change mapping record1900is shown in greater detail inFIG. 9. With respect toFIG. 9, there is illustrated a block diagram showing an exemplary change mapping record1, according to the preferred embodiment. With respect toFIG. 9, there is illustrated change mapping record1900. Within change mapping record1there is also provided proximate change mapping record3905and region record4910.

Returning again toFIG. 6, at step610, metrics generator345assigns a mapping record associated with a proximate change a context specific weight which represents the significance of the mapping record in comparison with a proposed change. A context specific weight is based on, for example, a weight of a proposed change. In this embodiment, if a proposed change to a section is significant, by using a weight of the proposed change, significance can also be placed on proximate (previous) changes that have been made to the section since a weight of a proximate change is also a factor in determining a context specific weight. In another embodiment, a context specific weight is based on a weight of a proximate change. In this embodiment, if a proximate change to a section is significant, by using a weight of the proximate change, significance can also be placed on a proposed change that has been made to the section since a weight of a proposed change is also a factor in determining a context specific weight. In still another embodiment, a context specific weight is based on overlap between a section associated with the proposed change and a section associated with the proximate change. This results in a mapping record associated with a proximate change having a more significant overlap with a proposed change to be treated as more significant.

In an example, a context specific weight is obtained by summing a weight of a proposed change and a weight of a proximate change and multiplying the sum by a percentage overlap between the changes as a proportion of a total number of lines associated with the changes, as provided by the following formula:
context specific weight=proposed weight+returned weight*(overlapSize/(sum(sizes))

For example, for the first proposed change and the associated first proximate change, a context specific weight for the mapping record of the first proximate change is calculated as follows:Proximate change mapping record1context specific weight:30+43*(4/(4+7))=26.55

For the second proposed change and the associated second proximate change, a context specific weight for the mapping record of the second proximate change is calculated as follows:Proximate change mapping record2context specific weight:1+13*(⅔+2)=5.6

Context specific weights can be used to decide which proximate changes to treat as the most important ones. Preferably, if multiple proximate changes are returned, proximate changes with relatively low context specific weights can be filtered out. Such low context specific weights can indicate a relatively low weight of a proposed change; a weight of a proximate change and/or percentage overlap.

At step615, resolver515executes a query in order to obtain each mapping record associated with the same mapping ID as the returned proximate change mapping records. This allows mapping records associated with the same link as that associated with the mapping records of the proximate changes to be determined such that a user has an expanded overview of changes that may be related to the proposed changes (wherein such changes may not necessarily be proximate to the proposed changes but are related to the proximate changes). For example, resolver515issues a query comprising “SELECT all where mapping ID=XYZ” resulting in a return of: Proximate change mapping record1; Proximate change mapping record2and Change mapping record1.

At step620, metrics generator345weights one or more mapping records associated with the link with an importance weight which represents the significance of the one or mapping records with the link in comparison with a proposed change. An importance weight is calculated using a multiplication of a weight of a mapping record associated with the link and the context specific weight—using the weight associated with the mapping record associated with the link allows importance to be placed on changes that are more significant over changes which are more trivial. Note that as weights of proximate changes have already been used as a factor in deriving a context specific weight, more significance is placed on such proximate changes over changes that are associated with the proximate changes under the same link. The importance weight is used to carry through data about which changes associated with the link are more significant such that relevant results can be displayed at a later stage to the user (this step will be discussed in more detail herein). An importance weight is calculated for each mapping record associated with the link against each context specific weight—this is because proximate changes associated with the same mapping record ID represents a set of related changes and significance should be given to this. Examples of importance weights are shown below:Proximate change mapping record1importance weights:43*26.55=1141.743*5.6=240.8Proximate change mapping record2importance weights:34*26.55=902.734*5.6=190.4Change mapping record1importance weights:13*26.55=345.213*5.6=72.8

In the example above, based on the proposed changes, proximate changes committed under the same work item have been retrieved. Equally, proximate changes committed under different work items can be retrieved and the above process would also be applied to such changes.

At step625, resolver515generates one or more region records. In one embodiment, a region record comprises an aggregation of proximate changes and further changes wherein such changes overlap. For example, resolver515generates the one or more region records in accordance with one or more rules. The one or more rules can include, for example, a rule that defines that specifies if a start offset and an end offset of a changed section is within 50% proximity of another changed section, associated mapping records will be merged into a single region record. The creation of one or more region records allows for a simplification of display of results as if such changes were each displayed separately. This can result in several results associated with the same or a similar section causing problems for the user, such as making the results difficult for the user to interpret or the most significant results not being readily apparent.

In the example provided herein, since proximate change mapping record1, proximate change mapping record2, and change mapping record1are associated with different files (and thusly have different file IDs), no overlap exists. Thus, resolver515generates a region record associated with each of the mapping records wherein: region record1is associated with proximate change mapping record1, region record2is associated with proximate change mapping record2, and region record3is associated with change mapping record1.

In another example, based on a proposed change, a proximate change associated with a further link is found and its associated mapping record is shown below:Proximate Change mapping record3Mapping record ID=145Code file ID=trunk/Docs/src/Installation.xmlRegion start offset=30Region end offset=40Timestamp=20/4/12 16:30Weight=20

In the another example herein, a section (especially lines30-40) associated with the proximate change mapping record3overlaps entirely with a section (lines28-48) associated with change mapping record1. Thus, at step625, resolver515generates a region record (region record4) wherein: region record4is associated with proximate change mapping record3and change mapping record1. Preferably, resolver515populates the region record with an average start offset and an average end offset based on an average of the start offsets and the end offsets of the associated mapping records.

At step630, metrics generator345populates the region record with a region importance weight. A region importance weight is the sum of each of the importance weights of the mapping records associated with the region record. This allows more significant region records to be highlighted.

In the remainder of the example below, region record1, region record2, and region record4will be used. Representations of on record1, region record2, and region record4are shown below:Region record1Region record ID=888Code file ID=trunk/Test/src/com/test/Test.javaAverage region start offset=46Average region end offset=52Region Importance Weight=1141.7+240.8=1382.5Region record 2Region record ID=777Code file ID=trunk/Test/src/com/test/Types.javaAverage region start offset=8Average region end offset=9Region Importance Weight=902.7+190.4=1113.1Region record4Region record ID=666Code file ID=trunk/Docs/src/Installation.xmlAverage region start offset=29Average region end offset=44Region Importance Weight=345.2+72.8+20=438

Region record1705is shown in greater detail inFIG. 7. Region record2805is shown in greater detail inFIG. 8. Region record4910is shown in greater detail inFIG. 9.

Preferably, resolver515sorts (at step630) the region records in order of region importance weight. The results of the sorting are depicted below:1. Region record 1=1382.52. Region record 2=1113.13. Region record 4=438

This sorting also allows some order to be imposed on the region records obtained as several such records could be obtained, potentially causing the user difficulty in interpretation. At step635, resolver515passes the sorted list to dependency display generator510which displays the list.

In the example herein, dependency display generator510displays a list of results starting with a pointer to the file Installation.xml and the associated lines29-44. Next, dependency display generator510displays a pointer to the file Test.java and the associated lines46-52. Finally, dependency display generator510displays a pointer to the file Types.java and the associated lines8-9. Preferably, display of the results can be executed in a variety of ways (e.g., if a user selects a result, the associated lines are highlighted within the file). In the preferred embodiment, dependency display generator510is operable to truncate the list for clarity. Furthermore, although resolver515sorts the list above based on size of region, resolver515can sort the list on any of the further data (e.g., recency of changes, similarity of the changes, and complexity of the changes).

Advantageously, the preferred embodiment allows a user, in response to making a change to a file, to be able to review sections of the file and/or sections of other files which may require updating also. For example, with reference toFIGS. 7-9, and as provided in the example above, in response to a user makes a change (e.g., proposed change1700and proposed change2800), the user is able to view a sorted list of further sections of files which may require updating (e.g., region record1705, region record2, and region record4910).

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fibre cable, RF, etc., or any suitable combination of the foregoing.