US20090210857A1 - Automated merging in a software development environment - Google Patents
Automated merging in a software development environment Download PDFInfo
- Publication number
- US20090210857A1 US20090210857A1 US12/033,651 US3365108A US2009210857A1 US 20090210857 A1 US20090210857 A1 US 20090210857A1 US 3365108 A US3365108 A US 3365108A US 2009210857 A1 US2009210857 A1 US 2009210857A1
- Authority
- US
- United States
- Prior art keywords
- changed
- merge
- elements
- list
- defect
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/33—Intelligent editors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
Definitions
- This invention relates generally to managing changed elements in a software development environment, and in particular to automated systems for merging multiple changed elements in projects within a software development environment.
- SCM Software configuration management
- 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.
- forward fitting 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.
- Changes may be made in response to a feature request or a bug report, or may result from the addition of new functionality to the software project.
- the number of feature requests, fixes, or additions may number in the hundreds or thousands, and the number of elements changed in response to each of these requests, fixes, and additions may number in the hundreds or thousands as well.
- elements may be shared between software projects, and therefore changes to elements made in the context of a first software project need to be merged not only into a first software project, but also into a further software project.
- the programmer can address this need after changes to an element in a first software project have been checked in by checking in a corresponding element for the further software project, adding the changed element to the further software project, and merging the changed element with the further software project; however, given a large volume of changes that may be made in even a single software project, this manual solution is onerous.
- the invention provides a method for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the method comprising obtaining a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and for each changed element thus listed, attempting a first automated merge of said changed element with its corresponding target.
- 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 obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
- a system for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the system comprising a data repository for storing at least one element associated with a software project, and for storing at least one changed element comprising a modified element; a data repository for storing at least one defect record, the defect record comprising a list of changed elements associated with a defect; and a software development environment interoperable with the data repository for storing at least one defect associated with a software project and for merging changed elements with a corresponding target, wherein the software development environment is configured to obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target; and for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
- FIG. 1 is a schematic representation of an element version history in a first project for an element in a software development environment
- FIG. 2 is a schematic representation of an element version history in a second project for the element of FIG. 1 ;
- FIG. 3 is a flowchart of a method for automated merging of changed elements in the software development environment
- FIG. 4 is a set of schematic representations of defect records in the software development environment
- FIG. 5 is a schematic representation of an element list in the software development environment.
- FIG. 6 is a schematic representation of a data processing system for implementing the method of FIG. 3 .
- 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.
- 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.
- FIG. 1 a schematic representation of an exemplary embodiment of a version-controlled element foo.c in the SDE is shown, with a main branch (comprising elements corresponding to releases A 100 and B 110 ) and two subbranches.
- a first subbranch comprises elements B/ 1 111 and B/ 2 112 , and may denote the revision history of the element in release B of the software project.
- the first change to version B of foo.c, version B/ 1 111 was made in response to an identified defect labelled “fix005” while the second change was made to version B/ 1 111 in response to another identified defect labelled “fix558”.
- a merge arrow 140 is drawn between version B/ 2 112 and C 120 , indicating that the changes to the element foo.c made in B/ 2 112 have been merged with the main branch of the version history at a target, C 120 .
- C 120 may represent the version of element foo.c that was included in release C of the software project. Modifications of the element foo.c 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.
- a second subbranch labelled “temp” is shown comprising two element versions (1) 115 and (2) 116 , which may represent further revisions made to the element version B 110 , but not yet integrated with the main branch of the version history. If it is determined that the changes to the element foo.c made in version (2) 116 should be merged with the released version of the element, then element version 2 ( 116 ) may be merged with the most recent released version of foo.c (here, C 120 ) at a target element destination D 130 .
- the merge function which incorporates the changes made to the changed element into a previous version of the same element for recording as a new, target element in the element's version history, 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.
- the SDE provides a graphical user interface to illustrate the relationship among the changes to the elements, such as the graphical representation of FIG. 1 a
- the SDE may also be configured to allow the user to insert merge arrows such as merge arrow 150 , or to otherwise create or insert annotations in the SDE regarding the changed elements and the target elements at which they were merged.
- merge arrows such as merge arrow 150
- 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.
- the annotations may be provided in the form of comment text or metadata stored in association with the changed element data, for example in the data repository.
- FIG. 1 may represent a view of the element in a first software project in a graphical user interface (GUI) of the SDE.
- GUI graphical user interface
- the element foo.c may also be used in a different software project, with either the same or different revision history.
- FIG. 2 illustrates a further representation of the element foo.c as it may be viewed in the context of a second software project, with a main branch comprising release version A 200 . If it is determined that changes made to the element foo.c in the first software project, resulting in the revision (2) 116 should be merged with the instance of the element in the second software project, then element revision (2) 116 may be merged with version A 200 at a target element destination, here labelled as B 210 . This merging action is shown in phantom with merge arrow 260 .
- FIGS. 1 and 2 illustrate a simple example of the evolution of a single element foo.c, and its use in different software projects within the SDE.
- 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, and a large number of change requests or fixes to be incorporated into the project, each affecting multiple elements.
- changes to that element in response to a change request or fix may need to be merged, not only with the project in which the modifications to the element were made, but with other software projects using that element.
- the SDE is provided with functionality for automatically merging changed elements on an element-by-element basis within a given software project, for example by means of a script or other function built into the SDE, the programmer or team responsible for the changed elements would still be required to manually identify each changed element and the corresponding software projects in which the changed element is to be merged.
- a defect may comprise a fault or unexpected behaviour identified in a software product, and 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.
- Defect record 410 may be a defect record associated with a first software project, such as the software project in which the modifications (1) 115 and (2) 116 were made to the element foo.c, as described above with reference to FIG. 1 .
- the defect record 410 may list a number of changed elements associated with the particular defect (numbered 578 ) represented in that record 410 ; here, the first changed element listed is the change to foo.c that is indicated in FIGS. 1 and 2 as (2) 116 .
- the precise annotation used as an identifier of the changed element may be varied; here, for example, the identifier of the element foo.c is in the format foo.c@@/main/my_proj/2, indicating that the version of foo.c referenced is the second modification in the subbranch labelled “my_prog”, which is split from the main branch “main”.
- the identifier of the changed element identifies, within the SDE, the individual version of the element in its element history among all elements and versions thereof stored in the data repository.
- the identifier may take another format, provided the element can be located in the data repository.
- the defect record 410 may also list other changed elements that are associated with the same defect, not shown.
- the defect record 410 may also include comments that describe the nature of the change, or other information that is useful for documenting the modifications made to the element.
- Other defects may be recorded in records 420 and 430 , which are associated with different software projects; in these examples, the same element version of foo.c is listed in the defect records, thus indicating that this changed element is associated with each of these other defects, even though these other defects may be associated with different software projects.
- a method for automated merging of changed elements by the SDE is illustrated in the flowchart of FIG. 3 .
- the process begins at block 310 , where a list of changed elements to be merged is required.
- This list of changed elements may be provided by the user, for example if a programmer has prepared a specific list of changed elements to be merged; if this element list is provided, the process moves to block 320 . If the element list is not provided, then the SDE may obtain or generate its own element list at block 315 by querying the defect database or other repository using a changed element or element identifier.
- the defect database may be queried for the defect record or records containing that changed element (for example, the defect records 410 , 420 , 430 .
- the SDE may be configured to handle a single defect associated with the changed element (the defect identifier may be provided by the user to the SDE) or multiple defects.
- an element list may be built, comprising the changed elements identified in the defect record, as well as other pertinent information that may be used by the SDE to complete a merge operation.
- a separate element list may be built for each identified defect listing the changed elements identified in each defect record, or alternatively a single element list may be built listing all changed elements associated with all identified defects.
- the element list or lists may also include any programmer-entered comments stored in association with the changed element, as well as a target for the merge operation, which may comprise the target destination for the merged element, or the previous version of the element with which the changed element is to be merged.
- This information may be retrieved from the data repository storing the changed element data itself, or it may be stored in the defect database as part of the defect record.
- An example of an element list 450 is shown in FIG. 5 .
- the next changed element in the element list is located in the data repository, and the SDE executes its own functions or scripts for merging the changed element at the specified target. If the merge operation is determined to have been a success at block 330 , then the process moves to block 370 , where the SDE records the successful merge result. In a further embodiment, this recordal may comprise a revision of metadata associated with the changed element to reflect a successful merge, or a flag or indicator marked in the element list 450 indicating that the changed element merge was completed.
- the SDE invokes a graphical, text, or other user interface to alert the user to the failed merging attempt, and to provide the user with an opportunity to manually complete the merging. If this manual merge is determined to be a success at block 350 , then the result is recorded at block 370 .
- the SDE may invoke a further routine at block 360 to generate a script that a user may use to invoke the merge function at a later date, or to invoke other tooling or functionality in the SDE to allow the user to make a decision regarding the merge.
- the attempt to merge is recorded at block 370 , for example by revising the metadata associated with the changed element to reflect that an attempt at merging was made, or to add a flag or indicator to the element list 450 indicating that the merge was attempted (but not completed).
- the SDE may simply record the outcome of the merge operation at block 370 , as described above.
- the SDE determines at block 375 whether there are further changed elements in the element list 450 for merging; if there are, the process returns to block 320 and proceeds as described above. If there are no further elements to be merged, then the SDE may create a report, which may include a list of merged elements, a list of unmerged elements, or both; a list comprise the element list 450 , with the addition of flags or indicators reflecting whether the merge of each listed element was successful or attempted.
- the SDE may be configured to re-attempt the merge of the listed elements that were not successful in a previous pass at block 390 , in which case the process resumes at block 320 with a revised element list.
- the revised element list may be an extract of the original element list 450 , listing only those elements that were not successfully merged.
- the user may configure the SDE to attempt automatic merging only without user intervention, avoiding the branch 340 - 350 - 360 for a first pass, and to re-attempt the merge for all elements in the element list 450 that were not merged successfully in a second pass in which the requests for manual intervention are invoked.
- this configuration saves user time, if it is determined after the first pass that the unmerged changed elements do not need to be merged at that time. It will further be appreciated that by executing the above-described method, the merging of numerous defects and changed elements across software projects may be delegated to another party, and need not be completed by the programmer or author who created the changed element or modified the defect record. If the delegate cannot make a determination regarding a merge operation at block 350 of the process, then the script generated at block 360 may be provided to an author of the changed element or original element for later consideration. The script may be forwarded automatically to the author by the SDE, if information regarding the author is also recorded in the changed element metadata or in the defect record.
- 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.
- the SDE may be embodied in software executable on an application server 40 resident on a network in communication with one or more client workstations 60 .
- the application server 40 may contain the data repository for the SDE; the data repository, or a portion thereof may be served from a database 50 resident on the application server 40 or from another server on the network.
- the systems' and methods' data may be stored in one or more media.
- the media can be 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.
- CDROM compact disc-read only memory
- CD-R/W compact disc-read/write
- 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.
- 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.
- 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.
- I/O devices 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.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
A system and method for merging changed elements in a software development environment is provided, in which the software development environment is provided with a set of at least one defect, comprising at least one changed element, associated with a software project that comprises a plurality of elements, the software project comprising a plurality of elements. The environment first obtains a list of changed elements in a defect record, for example from a defect database, and for each changed element in the list, attempts an automated merge of the changed element with a corresponding target. If any attempt fails, the environment may re-attempt the merge for any failed attempt, and may invoke a user interface for resolving the merge manually.
Description
- This invention relates generally to managing changed elements in a software development environment, and in particular to automated systems for merging multiple changed elements in projects within a software development environment.
- Software configuration management (SCM) systems allow users to manage multiple variants of the various objects or elements of software projects, 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.
- Changes may be made in response to a feature request or a bug report, or may result from the addition of new functionality to the software project. In a single release of a software product, the number of feature requests, fixes, or additions may number in the hundreds or thousands, and the number of elements changed in response to each of these requests, fixes, and additions may number in the hundreds or thousands as well. In addition, elements may be shared between software projects, and therefore changes to elements made in the context of a first software project need to be merged not only into a first software project, but also into a further software project. The programmer can address this need after changes to an element in a first software project have been checked in by checking in a corresponding element for the further software project, adding the changed element to the further software project, and merging the changed element with the further software project; however, given a large volume of changes that may be made in even a single software project, this manual solution is onerous.
- It is therefore desirable to provide a system and method in which changes to an element may be merged into multiple software projects on an automated or semi-automated basis, thereby minimizing user intervention. It is also desirable to provide this feature in a SCM system or other software development environment for managing multiple software projects sharing elements.
- In accordance with a first embodiment, the invention provides a method for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the method comprising obtaining a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and for each changed element thus listed, attempting a first automated merge of said changed element with its corresponding target.
- In accordance with a further aspect, a computer program product is provided, 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 obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
- In accordance with still a further aspect, a system is provided for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the system comprising a data repository for storing at least one element associated with a software project, and for storing at least one changed element comprising a modified element; a data repository for storing at least one defect record, the defect record comprising a list of changed elements associated with a defect; and a software development environment interoperable with the data repository for storing at least one defect associated with a software project and for merging changed elements with a corresponding target, wherein the software development environment is configured to obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target; and for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
- In drawings which illustrate by way of example only a preferred embodiment of the invention,
-
FIG. 1 is a schematic representation of an element version history in a first project for an element in a software development environment; -
FIG. 2 is a schematic representation of an element version history in a second project for the element ofFIG. 1 ; -
FIG. 3 is a flowchart of a method for automated merging of changed elements in the software development environment; -
FIG. 4 is a set of schematic representations of defect records in the software development environment; -
FIG. 5 is a schematic representation of an element list in the software development environment; and -
FIG. 6 is a schematic representation of a data processing system for implementing the method ofFIG. 3 . - 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
FIG. 1 , a schematic representation of an exemplary embodiment of a version-controlled element foo.c in the SDE is shown, with a main branch (comprising elements corresponding to releasesA 100 and B 110) and two subbranches. A first subbranch comprises elements B/1 111 and B/2 112, and may denote the revision history of the element in release B of the software project. As can be seen inFIG. 1 , the first change to version B of foo.c, version B/1 111, was made in response to an identified defect labelled “fix005” while the second change was made to version B/1 111 in response to another identified defect labelled “fix558”. Amerge arrow 140 is drawn between version B/2 112 andC 120, indicating that the changes to the element foo.c made in B/2 112 have been merged with the main branch of the version history at a target,C 120. C 120 may represent the version of element foo.c that was included in release C of the software project. Modifications of the element foo.c 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. - A second subbranch labelled “temp” is shown comprising two element versions (1) 115 and (2) 116, which may represent further revisions made to the
element version B 110, but not yet integrated with the main branch of the version history. If it is determined that the changes to the element foo.c made in version (2) 116 should be merged with the released version of the element, then element version 2 (116) may be merged with the most recent released version of foo.c (here, C 120) at a target element destination D 130. The merge function, which incorporates the changes made to the changed element into a previous version of the same element for recording as a new, target element in the element's version history, 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 ofFIG. 1 a, then the SDE may also be configured to allow the user to insert merge arrows such as merge arrow 150, or to otherwise create or insert annotations in the SDE regarding the changed elements and the target elements at which they were merged. 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. The annotations may be provided in the form of comment text or metadata stored in association with the changed element data, for example in the data repository. - The schematic representation of
FIG. 1 may represent a view of the element in a first software project in a graphical user interface (GUI) of the SDE. The element foo.c may also be used in a different software project, with either the same or different revision history.FIG. 2 illustrates a further representation of the element foo.c as it may be viewed in the context of a second software project, with a main branch comprisingrelease version A 200. If it is determined that changes made to the element foo.c in the first software project, resulting in the revision (2) 116 should be merged with the instance of the element in the second software project, then element revision (2) 116 may be merged with version A 200 at a target element destination, here labelled asB 210. This merging action is shown in phantom withmerge arrow 260. - The examples of
FIGS. 1 and 2 illustrate a simple example of the evolution of a single element foo.c, and its use in different software projects within the SDE. 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, and a large number of change requests or fixes to be incorporated into the project, each affecting multiple elements. Further, when a single element is used in multiple projects that are managed using the SDE, it is possible that changes to that element in response to a change request or fix may need to be merged, not only with the project in which the modifications to the element were made, but with other software projects using that element. If the SDE is provided with functionality for automatically merging changed elements on an element-by-element basis within a given software project, for example by means of a script or other function built into the SDE, the programmer or team responsible for the changed elements would still be required to manually identify each changed element and the corresponding software projects in which the changed element is to be merged. - Accordingly, in the preferred embodiment, a system and method are provided to allow for the automated merging of changed elements in one or more software projects on a defect-by-defect basis. A defect may comprise a fault or unexpected behaviour identified in a software product, and 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 defect records are shown in
FIG. 4 .Defect record 410, for example, may be a defect record associated with a first software project, such as the software project in which the modifications (1) 115 and (2) 116 were made to the element foo.c, as described above with reference toFIG. 1 . Thedefect record 410 may list a number of changed elements associated with the particular defect (numbered 578) represented in thatrecord 410; here, the first changed element listed is the change to foo.c that is indicated inFIGS. 1 and 2 as (2) 116. The precise annotation used as an identifier of the changed element may be varied; here, for example, the identifier of the element foo.c is in the format foo.c@@/main/my_proj/2, indicating that the version of foo.c referenced is the second modification in the subbranch labelled “my_prog”, which is split from the main branch “main”. The identifier of the changed element identifies, within the SDE, the individual version of the element in its element history among all elements and versions thereof stored in the data repository. The identifier may take another format, provided the element can be located in the data repository. Thedefect record 410 may also list other changed elements that are associated with the same defect, not shown. Thedefect record 410 may also include comments that describe the nature of the change, or other information that is useful for documenting the modifications made to the element. Other defects may be recorded inrecords - A method for automated merging of changed elements by the SDE is illustrated in the flowchart of
FIG. 3 . The process begins atblock 310, where a list of changed elements to be merged is required. This list of changed elements may be provided by the user, for example if a programmer has prepared a specific list of changed elements to be merged; if this element list is provided, the process moves to block 320. If the element list is not provided, then the SDE may obtain or generate its own element list at block 315 by querying the defect database or other repository using a changed element or element identifier. If the identifier of the first changed element is provided (for example foo.c), the defect database may be queried for the defect record or records containing that changed element (for example, the defect records 410, 420, 430. The SDE may be configured to handle a single defect associated with the changed element (the defect identifier may be provided by the user to the SDE) or multiple defects. For a single defect record, an element list may be built, comprising the changed elements identified in the defect record, as well as other pertinent information that may be used by the SDE to complete a merge operation. For multiple defects, a separate element list may be built for each identified defect listing the changed elements identified in each defect record, or alternatively a single element list may be built listing all changed elements associated with all identified defects. The element list or lists may also include any programmer-entered comments stored in association with the changed element, as well as a target for the merge operation, which may comprise the target destination for the merged element, or the previous version of the element with which the changed element is to be merged. This information may be retrieved from the data repository storing the changed element data itself, or it may be stored in the defect database as part of the defect record. An example of anelement list 450 is shown inFIG. 5 . - Returning to
FIG. 3 , atblock 320 the next changed element in the element list is located in the data repository, and the SDE executes its own functions or scripts for merging the changed element at the specified target. If the merge operation is determined to have been a success atblock 330, then the process moves to block 370, where the SDE records the successful merge result. In a further embodiment, this recordal may comprise a revision of metadata associated with the changed element to reflect a successful merge, or a flag or indicator marked in theelement list 450 indicating that the changed element merge was completed. - If the attempt at merging the changed element is determined at
block 330 to have been unsuccessful, for example as a result of a conflict between versions of the element being merged, then an optional branch in the process ofFIG. 3 may be followed to provide an opportunity for user intervention to resolve the merge. Atblock 340, the SDE invokes a graphical, text, or other user interface to alert the user to the failed merging attempt, and to provide the user with an opportunity to manually complete the merging. If this manual merge is determined to be a success atblock 350, then the result is recorded atblock 370. If the manual merge does not succeed, or if the user elects not to complete a manual merge, then the SDE may invoke a further routine atblock 360 to generate a script that a user may use to invoke the merge function at a later date, or to invoke other tooling or functionality in the SDE to allow the user to make a decision regarding the merge. The attempt to merge is recorded atblock 370, for example by revising the metadata associated with the changed element to reflect that an attempt at merging was made, or to add a flag or indicator to theelement list 450 indicating that the merge was attempted (but not completed). Alternatively, in place of the branch 340-350-360, when the merge is determined to have failed atblock 330, the SDE may simply record the outcome of the merge operation atblock 370, as described above. - The SDE then determines at
block 375 whether there are further changed elements in theelement list 450 for merging; if there are, the process returns to block 320 and proceeds as described above. If there are no further elements to be merged, then the SDE may create a report, which may include a list of merged elements, a list of unmerged elements, or both; a list comprise theelement list 450, with the addition of flags or indicators reflecting whether the merge of each listed element was successful or attempted. - The SDE may be configured to re-attempt the merge of the listed elements that were not successful in a previous pass at
block 390, in which case the process resumes atblock 320 with a revised element list. The revised element list may be an extract of theoriginal element list 450, listing only those elements that were not successfully merged. Thus, for example, the user may configure the SDE to attempt automatic merging only without user intervention, avoiding the branch 340-350-360 for a first pass, and to re-attempt the merge for all elements in theelement list 450 that were not merged successfully in a second pass in which the requests for manual intervention are invoked. It will be appreciated that this configuration saves user time, if it is determined after the first pass that the unmerged changed elements do not need to be merged at that time. It will further be appreciated that by executing the above-described method, the merging of numerous defects and changed elements across software projects may be delegated to another party, and need not be completed by the programmer or author who created the changed element or modified the defect record. If the delegate cannot make a determination regarding a merge operation atblock 350 of the process, then the script generated atblock 360 may be provided to an author of the changed element or original element for later consideration. The script may be forwarded automatically to the author by the SDE, if information regarding the author is also recorded in the changed element metadata or in the defect record. - 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 or defect. 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
FIG. 6 , the SDE may be embodied in software executable on anapplication server 40 resident on a network in communication with one ormore client workstations 60. Theapplication server 40 may contain the data repository for the SDE; the data repository, or a portion thereof may be served from adatabase 50 resident on theapplication server 40 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 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.
Claims (18)
1. A method for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the method comprising:
obtaining a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and
for each changed element thus listed, attempting a first automated merge of said changed element with its corresponding target.
2. The method of claim 1 , further comprising:
generating a further list comprising changed elements for which the merge was unsuccessful; and
for each changed element of the further list,
attempting a further automated merge of each of said changed elements for which the merge was unsuccessful with its corresponding target; and
if the further automated merge is unsuccessful, invoking a user interface for resolving the merge.
3. The method of claim 2 , wherein invoking a user interface for resolving the merge comprises:
providing a user interface for a user to manually merge the said changed element with its corresponding target;
if the said changed element is not manually merged, generating a script for invoking a merge function at a later time.
4. The method of claim 1 , wherein obtaining a first list of changed elements comprises querying a defect database comprising records of defects and associated changed elements.
5. The method of claim 4 , wherein the query comprises an identifier of a changed element.
6. The method of claim 2 , wherein generating a further list comprising changed elements for which the merge was unsuccessful comprises indicating, in the first list of changed elements, that the merge was attempted but not successful.
7. 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:
obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target, the defect record comprising a list of changed elements associated with a defect; and
for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
8. The computer program product of claim 7 , wherein the computer readable program causes the computer to:
generate a further list comprising changed elements for which the merge was unsuccessful; and
for each changed element of the further list,
attempt a further automated merge of each of said changed elements for which the merge was unsuccessful with its corresponding target; and
if the further automated merge is unsuccessful, invoke a user interface for resolving the merge.
9. The computer program product of claim 8 , wherein the computer readable program further causes the computer, when invoking a user interface for resolving the merge, to:
provide a user interface for a user to manually merge the said changed element with its corresponding target;
if the said changed element is not manually merged, generate a script for invoking a merge function at a later time.
10. The computer program product of claim 7 , wherein the computer readable program further causes the computer to, when obtaining a first list of changed elements, query a defect database comprising records of defects and associated changed elements.
11. The computer program product of claim 10 , wherein the query comprises an identifier of a changed element.
12. The computer program product of claim 8 , wherein the computer readable program further causes the computer to, when generating a further list comprising changed elements for which the merge was unsuccessful, indicate, in the first list of changed elements, that the merge was attempted but not successful.
13. A system for merging changed elements in a software development environment, the software development environment comprising a set of at least one defect associated with a software project, the software project comprising a plurality of elements, each defect being associated with at least one changed element comprising a modified version of an element, the system comprising:
a data repository for storing at least one element associated with a software project, and for storing at least one changed element comprising a modified element;
a data repository for storing at least one defect record, the defect record comprising a list of changed elements associated with a defect; and
a software development environment interoperable with the data repository for storing at least one defect associated with a software project and for merging changed elements with a corresponding target;
wherein the software development environment is configured to:
obtain a first list of changed elements in a defect record, the list comprising at least one changed element identifier and a corresponding target; and
for each changed element thus listed, attempt a first automated merge of said changed element with its corresponding target.
14. The system of claim 13 , wherein the software development environment is further configured to:
generate a further list comprising changed elements for which the merge was unsuccessful; and
for each changed element of the further list,
attempt a further automated merge of each of said changed elements for which the merge was unsuccessful with its corresponding target; and
if the further automated merge is unsuccessful, invoke a user interface for resolving the merge.
15. The system of claim 14 , wherein the software development environment is further configured to:
provide a user interface for a user to manually merge the said changed element with its corresponding target;
if the said changed element is not manually merged, generate a script for invoking a merge function at a later time.
16. The system of claim 13 , wherein the software development environment is further configured to query a defect database comprising records of defects and associated changed elements when wherein obtaining a first list of changed elements.
17. The system of claim 16 , wherein the query comprises an identifier of a changed element.
18. The method of claim 14 , wherein the software development environment is further configured to indicate, in the first list of changed elements, that the merge was attempted but not successful, when generating a further list comprising changed elements for which the merge was unsuccessful.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/033,651 US8495564B2 (en) | 2008-02-19 | 2008-02-19 | Automated merging in a software development environment |
US13/947,917 US9940108B2 (en) | 2008-02-19 | 2013-07-22 | Automated merging in a software development environment |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/033,651 US8495564B2 (en) | 2008-02-19 | 2008-02-19 | Automated merging in a software development environment |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/947,917 Continuation US9940108B2 (en) | 2008-02-19 | 2013-07-22 | Automated merging in a software development environment |
Publications (2)
Publication Number | Publication Date |
---|---|
US20090210857A1 true US20090210857A1 (en) | 2009-08-20 |
US8495564B2 US8495564B2 (en) | 2013-07-23 |
Family
ID=40956346
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/033,651 Expired - Fee Related US8495564B2 (en) | 2008-02-19 | 2008-02-19 | Automated merging in a software development environment |
US13/947,917 Active 2028-09-13 US9940108B2 (en) | 2008-02-19 | 2013-07-22 | Automated merging in a software development environment |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/947,917 Active 2028-09-13 US9940108B2 (en) | 2008-02-19 | 2013-07-22 | Automated merging in a software development environment |
Country Status (1)
Country | Link |
---|---|
US (2) | US8495564B2 (en) |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090210852A1 (en) * | 2008-02-19 | 2009-08-20 | International Business Machines Corporation | Automated merging in a software development environment |
US20130272419A1 (en) * | 2010-12-15 | 2013-10-17 | Sk Telecom Co., Ltd. | Method and apparatus for generating encoded motion information/recovering motion information using motion information integration, and image encoding/decoding method and apparatus using same |
US20140019934A1 (en) * | 2012-07-16 | 2014-01-16 | Uwe Schlarb | Generation framework for mapping of object models in a development environment |
US8924935B1 (en) * | 2012-09-14 | 2014-12-30 | Emc Corporation | Predictive model of automated fix handling |
US20150019564A1 (en) * | 2013-07-09 | 2015-01-15 | Oracle International Corporation | Method and system for reducing instability when upgrading software |
US9098364B2 (en) | 2013-07-09 | 2015-08-04 | Oracle International Corporation | Migration services for systems |
US9430229B1 (en) * | 2013-03-15 | 2016-08-30 | Atlassian Pty Ltd | Merge previewing in a version control system |
CN105988849A (en) * | 2015-03-06 | 2016-10-05 | 中兴通讯股份有限公司 | Application software upgrading method and apparatus |
US9588760B1 (en) * | 2015-11-24 | 2017-03-07 | International Business Machines Corporation | Software application development feature and defect selection |
US9747311B2 (en) | 2013-07-09 | 2017-08-29 | Oracle International Corporation | Solution to generate a scriptset for an automated database migration |
US9762461B2 (en) | 2013-07-09 | 2017-09-12 | Oracle International Corporation | Cloud services performance tuning and benchmarking |
US9792321B2 (en) | 2013-07-09 | 2017-10-17 | Oracle International Corporation | Online database migration |
US9805070B2 (en) | 2013-07-09 | 2017-10-31 | Oracle International Corporation | Dynamic migration script management |
US20170322799A1 (en) * | 2016-05-05 | 2017-11-09 | International Business Machines Corporation | Viewing section level changesets by timestamp in an integrated development environment |
US9967154B2 (en) | 2013-07-09 | 2018-05-08 | Oracle International Corporation | Advanced customer support services—advanced support cloud portal |
US9996562B2 (en) | 2013-07-09 | 2018-06-12 | Oracle International Corporation | Automated database migration architecture |
US10360129B2 (en) * | 2015-11-03 | 2019-07-23 | International Business Machines Corporation | Setting software error severity ranking |
US10776244B2 (en) | 2013-07-09 | 2020-09-15 | Oracle International Corporation | Consolidation planning services for systems migration |
CN111857802A (en) * | 2020-07-15 | 2020-10-30 | 上海云轴信息科技有限公司 | Method, system and equipment for merging request group integration |
US11036696B2 (en) | 2016-06-07 | 2021-06-15 | Oracle International Corporation | Resource allocation for database provisioning |
US11157664B2 (en) | 2013-07-09 | 2021-10-26 | Oracle International Corporation | Database modeling and analysis |
US11256671B2 (en) | 2019-09-13 | 2022-02-22 | Oracle International Corporation | Integrated transition control center |
US11294664B2 (en) * | 2020-06-05 | 2022-04-05 | CrossVista, Inc. | Version control system |
US11354118B2 (en) * | 2020-06-05 | 2022-06-07 | Cross Vista, Inc. | Version control system |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9092224B2 (en) * | 2013-05-14 | 2015-07-28 | Noblis, Inc. | Method and system to automatically enforce a hybrid branching strategy |
US10061688B2 (en) | 2013-05-14 | 2018-08-28 | Noblis, Inc. | Method and system to automatically enforce a hybrid branching strategy |
US10042742B2 (en) * | 2013-11-21 | 2018-08-07 | International Business Machines Corporation | Selective object testing in a client-server environment |
US10740093B2 (en) | 2016-09-01 | 2020-08-11 | Dropbox, Inc. | Advanced packaging techniques for improving work flows |
US10387153B2 (en) | 2017-11-27 | 2019-08-20 | Oracle International Corporation | Synchronizing a set of code branches |
US11455566B2 (en) * | 2018-03-16 | 2022-09-27 | International Business Machines Corporation | Classifying code as introducing a bug or not introducing a bug to train a bug detection algorithm |
US10509642B2 (en) * | 2018-03-30 | 2019-12-17 | International Business Machines Corporation | Intelligent discovery and application of API changes for application migration |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6560721B1 (en) * | 1999-08-21 | 2003-05-06 | International Business Machines Corporation | Testcase selection by the exclusion of disapproved, non-tested and defect testcases |
US6766334B1 (en) * | 2000-11-21 | 2004-07-20 | Microsoft Corporation | Project-based configuration management method and apparatus |
US20040205727A1 (en) * | 2003-04-14 | 2004-10-14 | International Business Machines Corporation | Method and apparatus for processing information on software defects during computer software development |
US20060136510A1 (en) * | 2004-12-17 | 2006-06-22 | Microsoft Corporation | Method and system for tracking changes in a document |
US7152224B1 (en) * | 2000-11-21 | 2006-12-19 | Microsoft Corporation | Versioned project associations |
US7251669B1 (en) * | 2003-03-31 | 2007-07-31 | Microsoft Corporation | System and method for database versioning |
US7266805B2 (en) * | 2004-12-22 | 2007-09-04 | Timesys Corporation | Systems and methods for generating software and hardware builds |
US20090210852A1 (en) * | 2008-02-19 | 2009-08-20 | International Business Machines Corporation | Automated merging in a software development environment |
US7603393B1 (en) * | 2007-04-02 | 2009-10-13 | Juniper Networks, Inc. | Software merging utility |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0528617B1 (en) * | 1991-08-19 | 1999-12-22 | Sun Microsystems, Inc. | Method and apparatus for change control in multiple development environments. |
US6601233B1 (en) * | 1999-07-30 | 2003-07-29 | Accenture Llp | Business components framework |
US6681382B1 (en) * | 2000-09-18 | 2004-01-20 | Cisco Technology, Inc. | Method and system for using virtual labels in a software configuration management system |
US7337124B2 (en) * | 2001-08-29 | 2008-02-26 | International Business Machines Corporation | Method and system for a quality software management process |
US6978441B2 (en) * | 2001-10-03 | 2005-12-20 | Sun Microsystems, Inc. | Rating apparatus and method for evaluating bugs |
US8032863B2 (en) * | 2004-11-18 | 2011-10-04 | Parasoft Corporation | System and method for global group reporting |
US9129038B2 (en) * | 2005-07-05 | 2015-09-08 | Andrew Begel | Discovering and exploiting relationships in software repositories |
US7743360B2 (en) * | 2005-07-05 | 2010-06-22 | Microsoft Corporation | Graph browser and implicit query for software development |
US7739653B2 (en) * | 2005-07-05 | 2010-06-15 | Microsoft Corporation | Representing software development item relationships via a graph |
US7614043B2 (en) * | 2005-08-26 | 2009-11-03 | Microsoft Corporation | Automated product defects analysis and reporting |
US8522207B1 (en) * | 2006-09-19 | 2013-08-27 | United Services Automobile Association (Usaa) | Systems and methods for automated centralized build/merge management |
US8370803B1 (en) * | 2008-01-17 | 2013-02-05 | Versionone, Inc. | Asset templates for agile software development |
-
2008
- 2008-02-19 US US12/033,651 patent/US8495564B2/en not_active Expired - Fee Related
-
2013
- 2013-07-22 US US13/947,917 patent/US9940108B2/en active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6560721B1 (en) * | 1999-08-21 | 2003-05-06 | International Business Machines Corporation | Testcase selection by the exclusion of disapproved, non-tested and defect testcases |
US6766334B1 (en) * | 2000-11-21 | 2004-07-20 | Microsoft Corporation | Project-based configuration management method and apparatus |
US7152224B1 (en) * | 2000-11-21 | 2006-12-19 | Microsoft Corporation | Versioned project associations |
US7251669B1 (en) * | 2003-03-31 | 2007-07-31 | Microsoft Corporation | System and method for database versioning |
US20040205727A1 (en) * | 2003-04-14 | 2004-10-14 | International Business Machines Corporation | Method and apparatus for processing information on software defects during computer software development |
US20060136510A1 (en) * | 2004-12-17 | 2006-06-22 | Microsoft Corporation | Method and system for tracking changes in a document |
US7266805B2 (en) * | 2004-12-22 | 2007-09-04 | Timesys Corporation | Systems and methods for generating software and hardware builds |
US7603393B1 (en) * | 2007-04-02 | 2009-10-13 | Juniper Networks, Inc. | Software merging utility |
US20090210852A1 (en) * | 2008-02-19 | 2009-08-20 | International Business Machines Corporation | Automated merging in a software development environment |
Non-Patent Citations (2)
Title |
---|
Eric Sinc, "Business Software: Source control how to [on line]", Source Gear, Chapter 3 (3 pages), August 26, 2004, (retreived from [http://www.ericsink.com/scm/source_control.html] on July 2, 2011). * |
Eric Sinc, "Business Software: Source control how to [on line]", Source Gear, Chapter 3 (5 pages), August 26, 2004, (retreived from [http://www.ericsink.com/scm/source_control.html] on July 2, 2011). * |
Cited By (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9304764B2 (en) | 2008-02-19 | 2016-04-05 | International Business Machines Corporation | Automated merging in a software development environment |
US20090210852A1 (en) * | 2008-02-19 | 2009-08-20 | International Business Machines Corporation | Automated merging in a software development environment |
US20130272419A1 (en) * | 2010-12-15 | 2013-10-17 | Sk Telecom Co., Ltd. | Method and apparatus for generating encoded motion information/recovering motion information using motion information integration, and image encoding/decoding method and apparatus using same |
US9270996B2 (en) * | 2010-12-15 | 2016-02-23 | Sk Telecom. Co., Ltd. | Method and apparatus for generating encoded motion information/recovering motion information using motion information integration, and image encoding/decoding method and apparatus using same |
US9888248B2 (en) | 2010-12-15 | 2018-02-06 | Sk Telecom Co., Ltd. | Method and apparatus for generating encoded motion information /recovering motion information using motion information integration, and image encoding/decoding method and apparatus using same |
US20140019934A1 (en) * | 2012-07-16 | 2014-01-16 | Uwe Schlarb | Generation framework for mapping of object models in a development environment |
US8856727B2 (en) * | 2012-07-16 | 2014-10-07 | Sap Se | Generation framework for mapping of object models in a development environment |
US8924935B1 (en) * | 2012-09-14 | 2014-12-30 | Emc Corporation | Predictive model of automated fix handling |
US9575764B1 (en) * | 2013-03-15 | 2017-02-21 | Atlassian Pty Ltd | Synchronizing branches of computer program source code |
US10915316B1 (en) | 2013-03-15 | 2021-02-09 | Atlassian Pty Ltd. | Correcting comment drift in merges in a version control system |
US10289407B1 (en) | 2013-03-15 | 2019-05-14 | Atlassian Pty Ltd | Correcting comment drift in merges in a version control system |
US9430229B1 (en) * | 2013-03-15 | 2016-08-30 | Atlassian Pty Ltd | Merge previewing in a version control system |
US9442983B2 (en) * | 2013-07-09 | 2016-09-13 | Oracle International Corporation | Method and system for reducing instability when upgrading software |
US20150019564A1 (en) * | 2013-07-09 | 2015-01-15 | Oracle International Corporation | Method and system for reducing instability when upgrading software |
US11157664B2 (en) | 2013-07-09 | 2021-10-26 | Oracle International Corporation | Database modeling and analysis |
US9747311B2 (en) | 2013-07-09 | 2017-08-29 | Oracle International Corporation | Solution to generate a scriptset for an automated database migration |
US9762461B2 (en) | 2013-07-09 | 2017-09-12 | Oracle International Corporation | Cloud services performance tuning and benchmarking |
US9792321B2 (en) | 2013-07-09 | 2017-10-17 | Oracle International Corporation | Online database migration |
US9805070B2 (en) | 2013-07-09 | 2017-10-31 | Oracle International Corporation | Dynamic migration script management |
US9491072B2 (en) | 2013-07-09 | 2016-11-08 | Oracle International Corporation | Cloud services load testing and analysis |
US10776244B2 (en) | 2013-07-09 | 2020-09-15 | Oracle International Corporation | Consolidation planning services for systems migration |
US9967154B2 (en) | 2013-07-09 | 2018-05-08 | Oracle International Corporation | Advanced customer support services—advanced support cloud portal |
US9996562B2 (en) | 2013-07-09 | 2018-06-12 | Oracle International Corporation | Automated database migration architecture |
US10198255B2 (en) | 2013-07-09 | 2019-02-05 | Oracle International Corporation | Method and system for reducing instability when upgrading software |
US10248671B2 (en) | 2013-07-09 | 2019-04-02 | Oracle International Corporation | Dynamic migration script management |
US9098364B2 (en) | 2013-07-09 | 2015-08-04 | Oracle International Corporation | Migration services for systems |
US10691654B2 (en) | 2013-07-09 | 2020-06-23 | Oracle International Corporation | Automated database migration architecture |
US10540335B2 (en) | 2013-07-09 | 2020-01-21 | Oracle International Corporation | Solution to generate a scriptset for an automated database migration |
CN105988849A (en) * | 2015-03-06 | 2016-10-05 | 中兴通讯股份有限公司 | Application software upgrading method and apparatus |
US10360129B2 (en) * | 2015-11-03 | 2019-07-23 | International Business Machines Corporation | Setting software error severity ranking |
US9588760B1 (en) * | 2015-11-24 | 2017-03-07 | International Business Machines Corporation | Software application development feature and defect selection |
US20170322799A1 (en) * | 2016-05-05 | 2017-11-09 | International Business Machines Corporation | Viewing section level changesets by timestamp in an integrated development environment |
US11036696B2 (en) | 2016-06-07 | 2021-06-15 | Oracle International Corporation | Resource allocation for database provisioning |
US11256671B2 (en) | 2019-09-13 | 2022-02-22 | Oracle International Corporation | Integrated transition control center |
US11822526B2 (en) | 2019-09-13 | 2023-11-21 | Oracle International Corporation | Integrated transition control center |
US11294664B2 (en) * | 2020-06-05 | 2022-04-05 | CrossVista, Inc. | Version control system |
US11354118B2 (en) * | 2020-06-05 | 2022-06-07 | Cross Vista, Inc. | Version control system |
US11847442B2 (en) | 2020-06-05 | 2023-12-19 | CrossVista, Inc. | Version control system |
US11875149B2 (en) | 2020-06-05 | 2024-01-16 | CrossVista, Inc. | Version control system |
CN111857802A (en) * | 2020-07-15 | 2020-10-30 | 上海云轴信息科技有限公司 | Method, system and equipment for merging request group integration |
Also Published As
Publication number | Publication date |
---|---|
US8495564B2 (en) | 2013-07-23 |
US9940108B2 (en) | 2018-04-10 |
US20130305214A1 (en) | 2013-11-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9940108B2 (en) | Automated merging in a software development environment | |
US9304764B2 (en) | Automated merging in a software development environment | |
US7401085B2 (en) | System and method for controlling the release of updates to a database configuration | |
US8954375B2 (en) | Method and system for developing data integration applications with reusable semantic types to represent and process application data | |
US7735062B2 (en) | Software development system and method | |
US8141029B2 (en) | Method and system for executing a data integration application using executable units that operate independently of each other | |
US8205189B2 (en) | Method and system for definition control in a data repository application | |
US9218137B2 (en) | System and method for providing data migration services | |
US20070067766A1 (en) | Infrastructure for the automation of the assembly of schema maintenance scripts | |
US20090083268A1 (en) | Managing variants of artifacts in a software process | |
US20070234328A1 (en) | File handling for test environments | |
US8086588B2 (en) | Computer program product and method for sharing information between multiple computer applications using a grafted model network | |
US20160085544A1 (en) | Data management system | |
EP1684170A2 (en) | Software development system and method | |
US20200097260A1 (en) | Software application developer tools platform | |
US9244706B2 (en) | Command line shell command generation based on schema | |
Predoaia et al. | Streamlining the development of hybrid graphical-textual model editors for domain-specific languages | |
Milanovic et al. | Model&metamodel, metadata and document repository for software and data integration | |
Tekinerdogan et al. | Impact of evolution of concerns in the model-driven architecture design approach | |
CN113885970A (en) | Method, system and medium for generating report data based on script | |
CN117687681B (en) | Version management method and system for low-code application | |
US20050108279A1 (en) | Method and dynamic system for the mangement and production of technical documentation in a database | |
Alves | Tool for Incremental Database Migration | |
Martin | Creating an Operator with Kubebuilder | |
Marjanovic | Developing a meta model for release history systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MARTINEAU, DAVID JOHN;REEL/FRAME:020528/0746 Effective date: 20080208 |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.) |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20170723 |