Automated merging in a software development environment

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

The present application is a continuation of U.S. patent application Ser. No. 12/033,609, filed Feb. 19, 2008. The disclosures of the prior applications are hereby incorporated in their entireties by reference.

TECHNICAL FIELD

This invention relates generally to managing changed elements in a software development environment, and in particular to automated systems for merging changed elements in a project within a software development environment.

DESCRIPTION OF THE RELATED ART

Software configuration management (SCM) systems allow users to manage multiple variants of the various objects or elements of software systems, and in particular may be configured to allow development teams to work in parallel in writing, modifying, porting, and upgrading software system elements while providing management or auditing tools for monitoring the changes made to the elements, and building software products from a plurality of elements. For example, the SCM may provide a check-out-edit-check-in model, in which an individual programmer may “check out” an element from a data repository, creating a local editable copy of the element, edit the element, then “check in” the element again in order to integrate the changes made with the data repository. The newly-changed element is stored as a new version of the element, and auditing features of the SCM may record information regarding the changes made. The SCM system may provide for the merging of a changed software element with other versions of the same base element to produce a new version of the element, sometimes referred to as “forward fitting”, as well as means to record information about the merge for future reference. The foregoing features may be provided in a single SCM product, or alternatively may be provided by software products that separately provide for configuration management and tracking defects and changes made to the elements stored in the data repository.

Each time a change to an element is made, it may be individually and manually merged into a new version of the element by the programmer who made the change. However, the scope of software development may encompass a number of programmers, hundreds or thousands of software elements, and hundreds or thousands of changes to elements; it is therefore undesirable to require that each and every change be manually merged. While the SCM system may provide for automated merging of all outstanding changes made to an element, a single element may be used in a number of different concurrent software projects; changes made to one version of an element for a first software project may not be required for a second software project.

It is therefore desirable to provide a system and method in which changes to an element may be selectively merged forward. It is further desirable to provide a system and method in which the merging of source code element changes is automated. It is also desirable to provide these features in a SCM system or other software development environment for managing multiple software projects sharing elements.

SUMMARY OF THE INVENTION

In accordance with a preferred embodiment, a method for selectively operating on changed elements in a software development environment is provided, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of version-controlled software development objects, each defect being associated with at least one changed element, each changed element comprising a modified version-controlled software development object, wherein the method comprises generating, for each of the changed elements in the software project, a work item comprising an identifier of the changed element, an operation for the changed element, and a target for said operation; generating a master work list comprising the said work items chronologically ordered; and for each unique version-controlled software development object associated with the changed elements of each work item in the master work list, executing all work items associated with the unique element in chronological order.

A further embodiment provides a computer program product comprising a computer usable medium embodying a computer readable program, wherein the computer readable program when executed on a computer providing a software development environment comprising a set of at least one defect associated with a software project wherein the software project comprises a plurality of version-controlled software development objects, each defect being associated with at least one changed element, and each changed element comprising a modified version-controlled software development object, causes the computer to generate, for each of the changed elements in the software project, a work item comprising an identifier of the changed element, an operation for the changed element, and a target for said operation; generate a master work list comprising the said work items chronologically ordered; and for each unique version-controlled software development object associated with the changed elements of each work item in the master work list, execute all work items associated with the unique element in chronological order.

Still a further embodiment provides a system for selectively operating on changed elements, comprising a data repository for storing version-controlled software development objects associated with a software project, and for storing at least one changed element comprising a modified version-controlled software development object; and a software development environment interoperable with the data repository for recording defects associated with a software project, for tracking changed elements, and for merging changed elements with a corresponding version-controlled software development object, wherein the software development environment is configured to generate, for each of the changed elements in the software project, a work item comprising an identifier of the changed element, an operation for the changed element, and a target for said operation; generate a master work list comprising the said work items chronologically ordered; and for each unique version-controlled software development object associated with the changed elements of each work item in the master work list, execute all work items associated with the unique element in chronological order, wherein the operation for each of the changed elements is selected from merging the changed element at the target and associating the changed element with the target, the target comprising a target version-controlled software development object.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate by way of example only a preferred embodiment of the invention,

<figref idref="DRAWINGS">FIGS. 1<i>a </i>and 1<i>b </i></figref>are schematic representations of element version histories in a software development environment;

<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart of a method for automated merging of changed elements in the software development environment;

<figref idref="DRAWINGS">FIG. 3</figref> is a further flowchart of the method of <figref idref="DRAWINGS">FIG. 2</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> is a schematic representation of defect records in the software development environment;

<figref idref="DRAWINGS">FIG. 5</figref> is a schematic representation of defect lists in the software development environment;

<figref idref="DRAWINGS">FIG. 6</figref> is a schematic representation of element lists in the software development environment;

<figref idref="DRAWINGS">FIG. 7</figref> is a schematic representation of work items in the software development environment;

<figref idref="DRAWINGS">FIG. 8</figref> is a schematic representation of further element version histories in the software development environment;

<figref idref="DRAWINGS">FIG. 9</figref> is a schematic representation of a master sorted work list in the software development environment;

<figref idref="DRAWINGS">FIG. 10</figref> is a schematic representation of sorted work lists and revised master sorted work lists in the software development environment; and

<figref idref="DRAWINGS">FIG. 11</figref> is a schematic representation of a data processing system for implementing the methods of <figref idref="DRAWINGS">FIGS. 2 and 3</figref>.

DETAILED DESCRIPTION

The following embodiments are described in the context of a software development environment (SDE), which may be provided in, or as part of, a software configuration management system (SCM), or in conjunction with other software management tools for tracking, managing, or auditing projects created and edited in the SDE. In a first embodiment, a data repository is provided. The data repository may be secure or permanent, and may by globally accessed at a central repository. The data repository may alternatively be provided in a distributed environment. The implementation of such a data repository will be understood by those skilled in the art.

The SDE may operate as a configuration management product, providing for version control of various files and projects stored in the data repository. A single software project may comprise a plurality of software development objects of different types, such as text files, graphics, directories, hyperlinks, and the like. These objects, hereinafter referred to as elements, are stored in the data repository. Changes to the elements may be stored as separate files (i.e., complete copies of the changed elements), or as deltas or weaves, which in a single stored instance of the element records the differences or changes for each version of the element, and the SDE may track changes made to various versions of a given element; thus, the data repository may store a plurality of version-controlled software development objects or elements. Elements may also be stored in compressed file formats. Techniques for the recording of element changes and file compression will be known to those of ordinary skill in the art. The project may further comprise derived objects, such as executable program files compiled from source code material. These derived objects in turn may also be versioned, for example generated for each corresponding version of the element from which the derived object was generated.

Referring to <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, a schematic representation of an exemplary embodiment of a version-controlled element in the SDE is shown, comprising both subbranches (comprising elements B/<b>1</b><b>111</b> and B/<b>2</b><b>112</b>, in a first example, and elements C/<b>1</b><b>121</b> and C/<b>2</b><b>122</b> as a second example) and a main branch (comprising elements A <b>100</b>, B <b>110</b>, C <b>120</b>, and D <b>130</b>). A given element, here foo.c, is initially created in a first version A <b>100</b>. This element <b>100</b> may be modified to provide a second version of the same element, version B <b>110</b>; it may be further modified to provide a third version of the same element, version C <b>120</b>. Modifications of the element <b>100</b> may be made for a number of reasons; for example, modifications may be created to address a need to fix a reported bug in the software, or to port a project to a different platform, or to create a customized version of the software for a customer. Regardless of the motivation for creating different versions of the original element A <b>100</b>, these versions may be developed in parallel. For example, versions B <b>110</b> and C <b>120</b> may represent versions of foo.c that coexist in released versions of a project incorporating that element. For each of these versions B <b>100</b> and C <b>120</b>, changes may be required to address specific requirements; in <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, it can be seen that a first change to version B of foo.c, version B/<b>1</b><b>111</b>, was made in response to an identified defect labelled “fix<b>004</b>”. A second change to version B, B/<b>2</b><b>112</b>, was made to version B/<b>1</b><b>111</b> in response to another identified defect labelled “fix<b>450</b>”. In the meantime, two changes were made to version C <b>120</b> of the element foo.c, resulting in versions C/<b>1</b><b>121</b> and C/<b>2</b><b>122</b>.

The example of <figref idref="DRAWINGS">FIG. 1<i>a </i></figref>depicts only a simple example of the evolution of a single element foo.c. The development effort in creating and updating a software product may of course incorporate hundreds or thousands of changes to various elements of the product, by a large number of developers; moreover, for a given software product, a project may comprise a large number of elements. It is also possible for a single element to be used in more than one project, but the changes that may be made to a given version of an element may not be required for all projects incorporating that element.

In the exemplary SDE, provision is made for automatically managing changes made to the various elements by merging changes to the elements forward into a new version, by combining the contents of two or more elements into a single new element. Changed elements may be merged from one subbranch to another subbranch, from one subbranch to the main branch, or from a main branch to a subbranch of the element history. In the example of <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, when the merging feature of the SDE is invoked, each outstanding change to a given version of an element is forward merged to create a new version of the element. Thus, in <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, when the automatic merging feature is invoked, the most recent version of element version B <b>110</b>, B/<b>2</b><b>112</b>, is forward merged with a target element, here the most recent version of element version C <b>120</b>, which is version C/<b>2</b><b>122</b>. The merging action is depicted by the merge arrow <b>150</b>. The resultant changed version of the element, C/<b>3</b><b>123</b>, is generated as a successor to version C/<b>2</b><b>122</b>. Further, this newly revised version of the element foo.c, C/<b>3</b><b>123</b>, may be merged into a new release version of the element D <b>130</b>. This further merge is depicted by the merge arrow <b>152</b>. In the example of <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, the merges are accomplished in a chronological order; the change B/<b>2</b><b>112</b>, being made to a version of the element foo.c preceding the version C <b>120</b>, is first merged with the changed version C/<b>2</b><b>122</b> to provide C/<b>3</b><b>123</b> before the new release version, D <b>130</b>, is generated.

The act of merging may be accomplished automatically by the SDE, for example by means of a script or other function built into the SDE. The merge function may be invoked by a command line interface, through a graphical user interface, or other means, and may also be accomplished manually by the user, if desired. If the SDE provides a graphical user interface to illustrate the relationship among the changes to the elements, such as the graphical representation of <figref idref="DRAWINGS">FIG. 1<i>a</i></figref>, then the SDE may also be configured to allow the user to insert merge arrows <b>150</b>, <b>152</b> to depict a merge relationship between various element versions, or to otherwise create or insert annotations in the SDE regarding the elements B/<b>2</b><b>112</b>, C/<b>2</b><b>112</b>, and so forth, to indicate that the changed element has been handled by a forward merge, and no longer represents an outstanding change that must be merged or otherwise addressed. These annotations are useful when the SDE also performs an auditing function or management function that requires tracking of the merge history of each and every changed element, or is configured to perform automatic merges of all outstanding, unmerged changed elements.

However, in some circumstances it may not be desirable to merge forward all outstanding changes to an element. Turning to <figref idref="DRAWINGS">FIG. 1<i>b</i></figref>, a second schematic representation of an exemplary embodiment of a version-controlled element in the SDE is shown for the same element, foo.c. The element again begins with a first version A <b>100</b>, and with similar versions and changes B<b>110</b>, B/<b>1</b><b>111</b>, B/<b>2</b><b>112</b>, C <b>120</b>, C/<b>1</b><b>121</b>, and C/<b>2</b><b>122</b>, but in this example, it is determined that it is not desirable to forward merge the changes made to version B/<b>1</b><b>111</b> (i.e., B/<b>2</b><b>112</b>) with the changes made to version C/<b>2</b><b>122</b>. However, it remains desirable to incorporate the changes of version C/<b>122</b> in a new release version D <b>130</b>′. This merge is depicted in <figref idref="DRAWINGS">FIG. 1<i>b </i></figref>as the merge arrow <b>154</b> between C/<b>2</b><b>122</b> and D <b>130</b>′.

If the SDE provides for automatic merging of all outstanding changed elements into new versions of the elements, as mentioned above, executing the automated merge function will result in a merging of all changed elements that were not previously annotated as having been merged. This is inconvenient, as the user will then have to manually reverse any merges that were not intended to be executed, thus increasing development time. Alternatively, if a changed element was intended to be merged into a new release of a first project, but not into a new release of a second project in which the element is used, the automated merging of the changed element into the second project may be avoided by creating an independently stored copy of this element; however, this will increase record-keeping overhead in the SDE overall, as the additional elements are created. Further, by creating independent copies of elements for use in other projects, the history of changes to the original element may be lost in the creation of the independent copies, thus requiring the programmer to keep track of multiple stored versions of the same element.

Accordingly, in this embodiment, a method is provided to allow for the automated merging of only selected changed elements. With reference to <figref idref="DRAWINGS">FIGS. 2 through 11</figref>, the SDE provides a system for tracking defects and merging changed elements. A defect may comprise a fault or unexpected behaviour identified in a software product, and here may also refer to a change request or other issue, where it is desirable to make a change to a release of the software product to accommodate a specific requirement. Records of defects may be stored within the SDE or in a data repository to which the SDE has access; these records may also contain information associating the defect with at least one changed element. A single defect or change request may involve changes to multiple elements in a single software project. When a defect (or change request) is entered in the SDE, a record for that defect is created. The records relating to defects may be stored in a database or other suitable record-keeping format, although a relational database format may be preferred. The SDE may provide functionality for the management of defects, including assigning a defect to a programmer or team of programmers, modification of the defect report, and tracking work done to address the identified defect.

Examples of partial records of defects are shown in <figref idref="DRAWINGS">FIG. 4</figref>. These schematic representations <b>170</b>, <b>180</b>, and <b>190</b> illustrate that a single defect (which may be a change request, rather than an identified bug or fault) may comprise changes to a number of elements in a project in the SDE; for example, defect record <b>170</b> comprises a record listing five changed elements, here labelled element<b>1</b>@@/main/releaseA/<b>1</b>, element<b>2</b>@@/main/releaseA/<b>4</b>, element<b>3</b>@@/main/releaseA/<b>2</b>, element<b>4</b>@@/main/releaseA/<b>3</b>, and element<b>5</b>@@/main/releaseA/<b>4</b>. The notation used in <figref idref="DRAWINGS">FIG. 4</figref> is in the format [element name]/[main]/[release version]/[change number]; thus, for example, element<b>2</b>@@/main/releaseA/<b>4</b> denotes that an element called “element<b>2</b>” has been modified to a release A version in the main branch of element<b>2</b>'s version history, and that this release A version has been modified at least four times. The defect record may further comprise comments or other annotations, such as the programmer's notes regarding the nature of the changes made to the corresponding elements. Exemplary schematic representations of some of the elements listed in <figref idref="DRAWINGS">FIG. 4</figref> are shown in <figref idref="DRAWINGS">FIG. 8</figref>. It will be appreciated that the schematic representation of the element versions also reflects a chronological history of the element; for example, in element<b>2</b>, the change element<b>2</b>@@/main/releaseA/<b>5</b> would have been made after the creation of element<b>2</b>@@/main/releaseA/<b>4</b>. The line connecting element<b>2</b>@@/main/releaseA/<b>4</b> and element<b>2</b>@@/main/releaseA/<b>5</b> illustrates the relationship between these two versions of element<b>2</b>, i.e. that element<b>2</b>@@/main/releaseA/<b>5</b> was derived from element<b>2</b>@@/main/releaseA/<b>4</b>. In the embodiment illustrated in <figref idref="DRAWINGS">FIG. 4</figref> and described below, the defects and changed elements may relate to a single release of a software product (e.g., release A) for incorporation into a subsequent release or subrelease. The systems and methods described herein, however, may be adapted to track elements and changed elements across multiple releases and subreleases.

Returning to <figref idref="DRAWINGS">FIG. 4</figref>, defects are further tagged in the SDE as being designated for incorporation or forward merging into a new release or version (also referred to as “forward fitting”), or as not intended for incorporation (merging) into a new release. For example, the schematic representations of the defects <b>170</b>, <b>180</b>, and <b>190</b> include the tags “FF” and “DNFF”, for “forward fit” and “do not forward fit”, respectively. Defect records <b>170</b> and <b>180</b> are marked for forward merging; defect record <b>190</b> is not. This tagging or marking is preferably done by the programmer or team working on the defect and making the changes to the identified elements.

When selected changed elements are to be merged, the method illustrated in <figref idref="DRAWINGS">FIGS. 2 and 3</figref> is followed. As a precondition, the defects in a given software project may be coded for merging or not. This is generally indicated at block <b>200</b> in the flowchart of <figref idref="DRAWINGS">FIG. 2</figref>. Alternatively, block <b>200</b> may comprise the process of querying the SDE database to verify that every outstanding defect up to a given integration time t_i(for example, all defects entered prior to a scheduled build date) have been appropriately marked as needing to be merged or not. If it is determined that outstanding defects entered before the integration time are not marked as “FF” or “DNFF” (or whatever other suitable indicia to indicate that the defect is to be merged or not merged), then these defects may be marked before proceeding with the automated selective merging process, or alternatively the criteria for selecting defects for the automated selective merging process may be adjusted to exclude these unmarked defects, for example by altering the integration time to exclude the unmarked defects.

Next, the SDE generates a list of defects that need to be merged at <b>210</b>, and a list of defects not to be merged at <b>205</b>, based on the outcome of queries of the defect database. These lists may comprise a list of defect indicia. In the example of <figref idref="DRAWINGS">FIG. 4</figref>, where three defects have been identified, it can be seen that the first two defects reflected in defect records <b>170</b>, <b>180</b>, labelled “defect <b>001</b>” and “defect <b>002</b>” respectively, are to be merged; the third defect in defect record <b>190</b>, “defect <b>003</b>”, is not to be merged. An example of a defect list comprising defects to be merged <b>310</b>, and of a defect list comprising defects that are not to be merged <b>320</b>, is represented schematically in <figref idref="DRAWINGS">FIG. 5</figref>.

From each of the foregoing lists, the SDE then creates a list of element versions that are to be merged at block <b>220</b> of <figref idref="DRAWINGS">FIG. 2</figref>, and a list of element versions that are not to be merged at block <b>215</b>, for example by querying the defect database. These element versions will correspond to the changed elements occurring after the integration time t_i. Exemplary schematic representations of a list of element versions that need to be merged <b>330</b> based on the defect list <b>310</b> and the defect records <b>170</b>, <b>180</b>, and of a list of element versions that do not need to be merged <b>340</b> based on the defect list <b>320</b> and the defect record <b>190</b>, are shown in <figref idref="DRAWINGS">FIG. 6</figref>. The examples of <figref idref="DRAWINGS">FIG. 6</figref> may be considered to be relatively short lists, since the number of defects to be merged (or not merged) in a single software project in the SDE may be large.

For each changed element to be merged, the SDE then obtains any accompanying comments provided by the programmer and stored in association with the changed element at block <b>230</b> of <figref idref="DRAWINGS">FIG. 2</figref>, and may also obtain other information about the changed element (e.g., the element type and other information about the element that may be stored automatically by the SDE, such as the identity of the programmer or team responsible for the changed element, the time of creation, and so forth). A work item is created at block <b>235</b> of <figref idref="DRAWINGS">FIG. 2</figref> based on the information thus obtained, comprising the file type, information extracted at block <b>230</b>, the defect number, and the target of the forward merge operation. Similarly, at block <b>225</b> of <figref idref="DRAWINGS">FIG. 2</figref>, the SDE creates a work item for each changed element that is not to be merged. Exemplary schematic representations of work items are shown in <figref idref="DRAWINGS">FIG. 7</figref>. Work item <b>350</b> is a merge work item, for a changed element that is to be merged at a target. The target may be an identifier of a new element version on either the main branch or a subbranch associated with that changed element's history; for example, the [target] field in the merge work item <b>350</b>, which describes the destination of the forward merge operation carried out on element<b>1</b>@@/main/releaseA/<b>1</b>, may be element<b>1</b>@@/main/releaseB/<b>0</b> (i.e., a new version of element<b>1</b> on the main branch). The work item <b>360</b> is a work item for a changed element that is not to be merged, but merely tracked; the work item <b>360</b> also includes a target, but the SDE will not actually forward merge the changed element with the identified target and will instead associate the changed element with the identified target.

After the work items are created, the SDE then combines the work items from blocks <b>225</b> and <b>235</b> of <figref idref="DRAWINGS">FIG. 2</figref> into a single master work list at block <b>240</b>, which may be sorted chronologically as shown in <figref idref="DRAWINGS">FIG. 9</figref>. If the SDE is capable of tracking and managing changes to directories as well as to files, then the sorted master work list may sort directories ahead of files when the master sorted work list is created. Thus, for example, if element<b>5</b> is a directory whilst all other identified elements are files, a master sorted work list <b>400</b>, as illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, will list work items for element<b>5</b> in chronological order in advance of other chronologically sorted work items. The chronological order may be provided by sorting the list by version, assuming that each version is numbered in chronological order; for example, element<b>2</b>@@/main/releaseA/<b>4</b> and element<b>5</b>@@/main/releaseA/<b>4</b> were each created before element<b>2</b>@@/main/releaseA/<b>5</b> and element<b>5</b>@@/main/releaseA/<b>5</b>. In a further embodiment, the list may be further sorted by defect.

Turning to <figref idref="DRAWINGS">FIG. 3</figref>, at least one further work list may be created from the master sorted work list. For each increment of a counter n initially set at block <b>245</b>, the master sorted work list <b>400</b> is inspected by the SDE at block <b>250</b> for work items. If the master sorted work list <b>400</b> contains work items, a first n^thsorted work list is created at block <b>255</b> by selecting the first unique element from the master list. In the example of the master sorted work list <b>400</b> of <figref idref="DRAWINGS">FIG. 1</figref>, the first such unique element is element<b>5</b>. <figref idref="DRAWINGS">FIG. 10</figref> depicts a schematic representation of a first sorted work list <b>410</b><i>a</i>, which lists the first unique changed element for each element from the master sorted work list <b>400</b>.

At block <b>260</b> of <figref idref="DRAWINGS">FIG. 2</figref>, a revised master sorted work list is created. The revised master sorted work list is computed as the difference between the previous master sorted work list and the n^thsorted work list just created; thus, in the example of <figref idref="DRAWINGS">FIG. 10</figref>, the revised master sorted work list <b>400</b><i>a </i>after first sorted work list <b>410</b><i>a </i>is created comprises the elements of the original master sorted work list <b>400</b> without the work items identified in the first sorted work list <b>410</b><i>a</i>. The counter n is then incremented at block <b>265</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

If the SDE determines at block <b>250</b> that the revised master sorted work list <b>400</b><i>a </i>still contains work items, then blocks <b>255</b>, <b>260</b>, and <b>265</b> are repeated for the next unique element in the revised master sorted work list <b>400</b><i>a</i>. In the revised master sorted work list <b>400</b><i>a</i>, there remain three unique element entries (elements<b>5</b>, <b>2</b>, and <b>3</b>); thus, the second sorted work list <b>410</b><i>b</i>, as depicted in <figref idref="DRAWINGS">FIG. 10</figref>, comprises the next set of work items relating to these three unique elements. Still a further revised master sorted work list <b>400</b><i>b </i>is then generated, which excludes the work items listed in the second sorted work list <b>410</b><i>b</i>. This process repeats as necessary; in the example illustrated by <figref idref="DRAWINGS">FIG. 10</figref>, after the third work list <b>410</b><i>c</i>, which contains the last unique work items for element<b>3</b>, is created, no further work items remain. Had further unique work items remained, then further revised master work lists and further sorted work lists would be generated as necessary until the SDE determines at block <b>250</b> that the revised master sorted work list does not contain any further work items.

It will be appreciated by those skilled in the art that the precise methodology of generating the n work lists may not require the explicit creation of revised master work lists. For example, a process may be executed by which each of the n work lists <b>410</b><i>a</i>, <b>410</b><i>b</i>, <b>410</b><i>c</i>, etc. is generated by scanning the contents of the master sorted work list <b>400</b>, and selecting or pointing to elements from the master sorted work list <b>400</b>, without generating or storing revised versions of the master sorted work list <b>400</b> itself. In that case, the flowchart branch <b>255</b>-<b>260</b>-<b>265</b> may terminate when the SDE determines that the end of the master sorted work list <b>400</b> has been reached.

After the SDE determines that no further work items are to be placed in one of the n work lists at <b>250</b>, the process continues at block <b>270</b> of <figref idref="DRAWINGS">FIG. 3</figref>. A counter m is set to an initial value of 1. At block <b>275</b>, work list m is executed. Thus, in the example of <figref idref="DRAWINGS">FIG. 10</figref>, the SDE executes the merge of element<b>5</b>@@/main/releaseA/<b>4</b> at the target element specified in the work list <b>410</b><i>a</i>, and records this changed element as merged with the target element. If a merge arrow or other graphical notation may be entered in a graphical representation of the element's version history, the SDE may also execute the necessary script or store the necessary instruction so that the merge arrow or other notation is created. The SDE also executes the merge item instructions for element<b>1</b>@@/main/releaseA/<b>1</b>, element<b>2</b>@@/main/releaseA/<b>4</b>, element<b>3</b>@@/main/releaseA/<b>1</b>, element<b>4</b>@@/main/releaseA/<b>3</b>, and the track item instruction for element<b>9</b>@@/main/releaseA/<b>3</b>. For the latter track item instruction, the SDE records the changed element as having been tracked; although the changed element is not merged with its target, the SDE may record information associated with the target element for auditing purposes indicating that the changed element has been handled. The SDE may also record, in association with the target of the track item instruction (in the corresponding example shown in <figref idref="DRAWINGS">FIG. 8</figref>, element<b>9</b>@@/main/releaseB/<b>0</b>), an identification of the source changed element so that it can be easily determined from an inspection of the target element that it has incorporated changes from a predecessor version. If a conflict during the execution of a work list is detected, the SDE may invoke conflict-resolving routines at block <b>280</b>. These routines may comprise manual resolution of the conflict by the user. Thus, conflict resolution <b>280</b> may take place during the execution of the work list <b>275</b>, and not after the execution of the work list is completed.

Next, the counter m is incremented at block <b>285</b>, and the SDE determines at block <b>290</b> whether there are any further work lists to be executed. If there are further work lists, then the process of blocks <b>275</b>-<b>280</b>-<b>285</b>-<b>290</b> is repeated until the SDE determines that there are no further work lists at block <b>290</b>, at which point the process terminates. The incremented counter m is provided so that the work lists <b>410</b><i>a</i>, <b>410</b><i>b</i>, etc. are executed in chronological order; other means for repeating blocks <b>275</b>, <b>280</b> and <b>290</b> may be implemented in this process such that the work lists are executed in chronological order. In this manner, the SDE attempts the merge or tracking of a first version of each element in the sorted work list, before moving on to attempt the merge or tracking of a subsequent version of the same element in a subsequent sorted work list. By implementing the individual sorted work lists described above, a form of “batch” processing of merge and track item tasks is accomplished, and the risk of conflict arising between two instructions within a single sorted work list is minimized since each instruction within the sorted work list relates to a unique element.

The defects that were handled during the processes of <figref idref="DRAWINGS">FIG. 2</figref> and <figref idref="DRAWINGS">FIG. 3</figref> may be marked in the SDE has having been completed. In this manner, all changed elements that are designated for merging are automatically merged, subject to any manual conflict resolution, and changed elements resulting from defects that are not intended to be merged are not merged, but are properly documented for auditing purposes. All merging can be handled by a single person, since much of the decision-making as to whether a changed element is to be merged is automated.

<figref idref="DRAWINGS">FIG. 8</figref> illustrates a series of elements referenced in the defect records <b>170</b>, <b>180</b>, <b>190</b>. The state of the changed elements prior to the execution of the processes of <figref idref="DRAWINGS">FIGS. 2 and 3</figref> is represented by the elements depicted in solid lines, and the integration time t_iis indicated. The phantom lines and target elements of <figref idref="DRAWINGS">FIG. 8</figref> illustrate the state of each of these elements after the processes of <figref idref="DRAWINGS">FIGS. 2 and 3</figref> are completed. In each case, it is presumed that the target for each changed element is a new version of the element on the main branch; thus, in the example of element<b>1</b>, changed elements A/<b>1</b> is merged to the target version B. In the example of element<b>5</b>, changed element A/<b>4</b> is merged to element version B; changed element A/<b>5</b>, which as described above was created in response to a defect that was not to be forward fitted, is merely tracked at element version B; however, the phantom merge arrow leading from A/<b>5</b> to version B indicates to the user that the changed element, although unmerged, has been tracked in version B for auditing purposes.

The data stored in association with the various changed elements—the merge data or other documentation, comments, identity of the programmer or team responsible for the changed element or defect, and so forth—may be stored as metadata associated with the changed element. The SDE may comprise elements to provide all functionality described above in a single, integrated product, or alternatively aspects of the SDE described above may be provided in a plurality of software development, defect tracking, and management tools. Referring to <figref idref="DRAWINGS">FIG. 11</figref>, the SDE may be embodied in software executable on an application server <b>40</b> resident on a network in communication with one or more client workstations <b>60</b>. The application server <b>40</b> may contain the data repository for the SDE; the data repository, or a portion thereof may be served from a database <b>50</b> resident on the application server <b>40</b> or from another server on the network.

The systems and methods disclosed herein are presented only by way of example and are not meant to limit the scope of the invention. Other variations and modifications of the systems and methods described above will be apparent to those skilled in the art and as such are considered to be within the scope of the invention, which includes all such variations and modifications as fall within the scope of the appended claims. For example, it should be understood that acts and the order of the acts in the processing described herein may be altered, modified and/or augmented, or that said acts may be carried out by software and/or hardware modules designed for such purpose, and still achieve the desired outcome.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The systems' and methods' data may be stored in one or more media. The media can be memory comprised in many different types of storage devices and programming constructs, such as RAM, ROM, Flash memory, programming data structures, programming variables, etc. It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program. Media can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disc-read only memory (CDROM), compact disc-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. In a data processing system, the components, software modules, functions and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Various embodiments of the present invention having been thus described in detail by way of example, it will be apparent to those skilled in the art that variations and modifications may be made without departing from the invention. The invention includes all such variations and modifications as fall within the scope of the appended claims.