Operation support in versioning systems

Implementations of the present disclosure provide a computer-implemented method that includes accessing computer code from a repository at a computer, registering a plurality of operations on the computer code at the computer, generating a changelist based on the operations, the changelist comprising a plurality of computer code objects affected by the operations, initiating a reversion operation to revert one or more of the computer code objects to a previous state, partitioning the computer code objects to provide independent first and second partitions, the first partition including an object set based on the computer code objects, and executing the reversion operation based on only the first partition including the object set.

BACKGROUND

An organization that performs software development can use software configuration management (SCM) to track and control changes in a software project during the software development process. SCM can identify the functional and physical attributes of the software components (e.g., source code files) for the software project at various points in time. SCM can also manage changes to identified attributes of the software components in order to maintain integrity and traceability for the software project throughout the entire software development process.

A SCM system can include revision control. Revision control can track and manage changes to software components. A SCM system that includes revision control can manage software component changes in an environment where the software development is by a team of developers where each member of the team can access and share each software component.

SUMMARY

Implementations of the present disclosure provide a computer-implemented method that includes accessing computer code from a repository at a computer, registering a plurality of operations on the computer code at the computer, generating a changelist based on the operations, the changelist comprising a plurality of computer code objects affected by the operations, initiating a reversion operation to revert one or more of the computer code objects to a previous state, partitioning the computer code objects to provide independent first and second partitions, the first partition including an object set based on the computer code objects, and executing the reversion operation based on only the first partition including the object set.

In some implementations, initiating the reversion operation comprises receiving an identification of an object of the plurality of computer code objects for reversion, and partitioning comprises generating the object set based on the object.

In some implementations, initiating the reversion operation comprises receiving an identification of an operation of the plurality of operations for reversion, and partitioning comprises generating the object set based on the operation.

In some implementations, the method further includes generating an operation set comprising a plurality of affected operations, wherein executing the reversion operation is further based on the operation set.

In some implementations, partitioning the computer code objects includes generating the object set including an object to be reverted, generating an operation set including an affected operation, determining that another object corresponds to the affected operation, and adding the other object to the object set.

In some implementations, partitioning the computer code objects includes generating an operation set including an operation to be reverted, generating the object set including an affected object, determining that another operation corresponds to the affected object, and adding the other operation to the operation set.

In some implementations, at least one of the operations includes a refactoring operation.

The present disclosure further provides a system for implementing the methods provided herein. The system includes a database having computer code stored thereon, and a computer that is in communication with the database, the computer processing instructions to cause one or more processors to perform operations in accordance with implementations of the methods provided herein.

It is appreciated that methods in accordance with the present disclosure can include any combination of the aspects and features described herein. That is to say that methods in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

DETAILED DESCRIPTION

Referring now toFIG. 1, a schematic illustration of an exemplar system100in accordance with implementations of the present disclosure can include a plurality of clients108,110, and a computer system114. The computer system114can include an application server102and a database104. The computer system114and the clients108,110can be connectively coupled for communication over a network106.

In some implementations, the system100can be a distributed client/server system that spans one or more networks such as network106. In some implementations, each client (e.g., clients108,110) can communicate with the application server102via a virtual private network (VPN), Secure Shell (SSH) tunnel, or other secure network connection. In some implementations, the network106can include the Internet, a wireless service network and may also include the Public Switched Telephone Network (PSTN). In other implementations, the network106may include a corporate network (e.g., an intranet) and one or more wireless access points.

Each client (e.g., clients108,110) can establish its own session with the application server102. Each session can be semi-permanent as it can be established at one point in time and torn down at another. Each session can involve two-way information exchange between the computer system114and each individual client108,110. For example, a Hypertext Transfer Protocol (HTTP) session can allow the association of information with individual users. A session can be stateful where at least one of the communicating parts (e.g., the application server102or the client (e.g., clients108,110)) can save information about the session history in order to be able to communicate. Alternatively, stateless communication includes independent requests with associated responses.

Multiple clients (e.g., clients108,110) can communicate via network106with the application server102. In order to run an application each client (e.g., clients108,110) can establish a corresponding session with the application server102. For example, the database104can store software components for a software development project in a central repository. An application server (e.g., application server102) can host a software configuration management (SCM) application. Use of the SCM application by developers working on a software project can prevent multiple developers from accessing and editing the same source code file in the central repository at the same time. For example, developers using a plurality of clients (e.g., clients108,110) can run the SCM application on the application server102to access source code files stored in a central repository in the database104.

In some implementations, the SCM application can allow a first developer to lock a source code file in the central repository for editing (e.g., check-out). If a first developer checks out a source code file, no other developer can obtain write access to the source code file. A developer can check-out a source code file, which places a working copy of the source code file in the central repository on the developer's client. Other developers may read the source code file in the central repository but other developers cannot change the source code file. Once the first developer unlocks the file (e.g., either checks-in the source code file, which may be an updated version of the file, or performs an undo of the check-out where the source code file in the central repository remains unchanged) other developers can access the file. In this type of SCM application, only one developer at a time can edit a source code file in the central repository.

In some implementations, a SCM application can allow multiple developers to edit the same source code file in the central repository at the same time (e.g., multiple developers can check-out the same source code file from the central repository). A first developer can check-out a source code file (e.g., a copy of the source code file in the central repository can be downloaded to the first developer's local client (e.g., client108) and used by the first developer as a working copy of the source code file). A second developer can check-out a source code file (e.g., a copy of the source code file in the central repository can be downloaded to the second developer's local client (e.g., client110) and used by the second developer as a working copy of the source code file). A first developer can check-in the changes made to the local copy of the source code file to the central repository. The SCM system can include functions to allow the second developer, also editing the source code file, to check-in their local changes to the source code file by merging their changes into the source code file in the central repository (where the source code file in the central repository now includes changes made by the first developer). The SMC application can preserve changes made to the source code file by the first developer when incorporating the changes made to the source code file by the second developer.

A changelist, which can also be referred to as activities, can identify a group or set of changes made by a developer to a local copy of source code files at single check-in. The changelist can include the changes made by the developer on the local copy of the source code files from check-out of the files until check-in of the files. The developer can collect changes made to the local copy of the source code files in the changelist. When the developer determines the source code changes are consistent and available for sharing with other developers, the developer can check-in the source code files, which submits the changes to the files to the SCM application. The SCM application can use the changelist to incorporate the changes made by the developer in the local copy of the source code files into the corresponding source code files in the central repository.

In some implementations, the SCM application can save a version of a source code file after each developer operation on the local client responsible for the check-out of the file. The changelist can represent a sequential view of source code edits by the developer. The SCM application can view a historical version of the source code at a particular time during the editing of the file using a changelist identification (ID). For example, a developer, using a local client (e.g., client108) can connect to an application server (e.g., application server102) by way of a network (e.g., network106). The developer can run a SCM application hosted on the application server (e.g., application server102). The developer can check-out a source code file for editing, (the SCM application can download a copy of the source code file from the central repository (e.g., database104) to the local client (e.g., client108)). Upon initial check-out, the SCM application can generate a changelist. In some implementations, the SCM application can place the changelist on the developer's local client (e.g., client108) in a local changelist file. In some implementations, the SCM application can place the changelist on the application server (e.g., application server102) in a changelist file.

SCM applications that allow atomic multi-change check-ins can rely on changelists to maintain a central repository in a consistent state. For example, if an operation on the central repository is interrupted before completion, the changelist can ensure that the repository will not be left in an inconsistent state.

In some implementations, a developer during a software development process may perform one or more consolidation or “clean-up” processes on an existing source code base. The developer can perform the consolidation process to improve the overall quality, readability, maintainability, or extensibility of the existing source code base at that point in the development process. The consolidation process can simplify the code structure.

One exemplar type of consolidation process can be refactoring. Refactoring operations can improve an existing source code base by changing the internal structure of the code without changing the external behavior of the code. Refactoring an existing source code base can produce a revised source code base that does not add new functionality to the source code. However, the revised source code base may be easier to understand, use and maintain.

In some implementations, a consolidation process can be a mass operation. A mass operation can perform an operation on a plurality of objects in a source code base at the same time. For example, a mass operation can be the deletion of a specific number of objects at the same time. In some implementations, a refactoring operation can be a mass operation. However, a refactoring operation can implement additional functions along with a mass operation.

In some implementations, a source code file can include one or more software objects (computer code objects). A developer or team of developers can design and implement the software objects. Examples of software objects can include, but are not limited to, code files, configuration objects, internet content and security roles. Each software object can have a unique name. The object can store its state in fields or variables and expose its behavior through methods or functions. Objects allow for data encapsulation and can be used in object-oriented programming. In some implementations, a refactoring operation may affect one or more source code files and can affect a multitude of software objects (e.g., 10 to 500 objects). In some implementations, a developer may need to perform a plurality of refactoring operations on an existing source code base in order for the revised source code base to reach a consistent state. The developer can check-out the source code files needed to perform the refactoring operations from the existing source code base. The developer can perform a series of refactoring operations on the local checked-out source code files. A changelist can collect and record the changes performed by the developer (the refactoring operations) to the source code files. When the revised source code reaches a consistent state, the developer can then check-in the revised source code files updating the source code in the central repository. An SCM application can use the changelist to incorporate the changes made by the developer in the local copies of the source code files into the source code files in the central repository.

In some implementations, while performing a series of refactoring operations, a developer may perform a single refactoring operation in error. For example, the developer may perform an incorrect refactoring operation in the series of refactoring operations. In another example, the developer may not correctly perform one of the refactoring operations in the series of refactoring operations. In some implementations, while performing a series of refactoring operations, a developer may perform an additional refactoring operation in an attempt to return the source code base to a stable state. If unsuccessful, the developer may want to revert the refactoring operation and return the source code to the previous state prior to the refactoring operation.

In some implementations, in order for the developer to revert a refactoring operation in a series of refactoring operations, the developer can revert or discard the entire series of refactoring operations (e.g., the developer can undo the check-out of the source code resulting in no changes to the existing source code base in the central repository). This can result in the loss of all refactoring operations since the last successful check-in of the source code base (the source code base will remain the same; it will not be revised). Additionally, in some implementations, in order for the developer to undo a refactoring operation in a series of refactoring operations, the developer can undo the series of refactoring operations on an object-by-object basis for each object involved in the series of refactoring operations. The objects can be reverted to their state prior to the performance of any refactoring operations. A developer may perform either correction in order to return the source code base to a stable state. In order to implement either correction, developers can loose a significant amount of development time undoing or discarding the refactoring operations.

In some implementations, a developer may perform a series of refactoring operations a single operation at a time. For example, the developer can check-out the source code for the single refactoring operation, perform the refactoring operation, verify the integrity of the source code base and check-in (e.g., submit the changelist) the revised source code reflective of the single refactoring operation. The developer can follow this process for each refactoring operation. If a refactoring operation fails, as described above, the developer can revert the changelist for the single refactoring operation (e.g., the developer can undo the check-out) or the developer can manually undo the single refactoring operation object by object. In this case, only the last refactoring operation is lost. However, this can be a time consuming process as the developer confirms the integrity of the source code base after each refactoring operation. Additionally, a plurality of refactoring operations may be necessary in order to return a code base to a stable state.

Referring now toFIG. 2A, an exemplar changelist202that can be generated in accordance with implementations of the present disclosure is shown. As described above, a changelist can identify a set of changes made by a developer in source code files at a single check-in of the files.

A developer may perform a series of refactoring operations on an existing source code base. For example, a developer, using a local client (e.g., client108) can connect to an application server (e.g., application server102) by way of a network (e.g., network106). The developer can run a SCM application hosted on the application server (e.g., application server102). The developer can check-out one or more source code files that may include one or more objects for one or more refactoring operations (the SCM application can download copies of the source code files from the central repository (e.g., database104) to the local client (e.g., client108)). Upon initial check-out of one or more source code files, the SCM application can generate a changelist on the developer's local client (e.g., client108) in a local changelist file.

In some implementations, the changelist can include an operation entity. The operation entity can include one or more object identifiers. The operation entity can be associated with a refactoring operation. Each object identifier can be associated with a software object adapted by the refactoring operation associated with the operation entity. In the example inFIG. 2A, a developer can perform a series of refactoring operations208. The changelist202can include operation entities204a-f. Refactoring operations208a-fcan be associated with operation entities204a-f, respectively. A plurality of object identifiers206(fifty in the exemplar case ofFIG. 2A) can be included in operation entity204a. Each object identifier206can be associated with a software object (e.g., object identifier206acan be associated with software object1) adapted by the refactoring operation208a.

For example, refactoring operation208acan be a renaming operation (e.g., “rename object1”, where object identifier206acan be associated with software object1). Refactoring operation208acan involve the adaptation of fifty different objects (e.g., object1and an additional forty-nine objects, objects2-50) associated with object identifiers206in the operation entity204ain the changelist202. Upon completion of the refactoring operation208a, the changelist202can be updated to include operation entity204aas in changelist view202a. The developer may not check-in the resultant revised source code as adaptations of one or more software objects may need to be performed in order to put the source code into a consistent stable state. The developer can continue to perform refactoring operations (e.g., refactoring operations208b-e).

The changelist can be updated as the developer performs each refactoring operation. For example, operation entity204bcan be associated with refactoring operation208b. A plurality of object identifiers210can be included in operation entity204b. Each object identifier210can be associated with a software object (e.g., object identifier210acan be associated with software object51) adapted by the refactoring operation208b. Refactoring operation208bcan involve the adaptation of the plurality of different objects (e.g., objects51-100) associated with object identifiers210in the operation entity204bin the changelist202. Upon completion of the refactoring operation208b, the changelist202can be updated to include operation entity204bas shown in changelist view202b.

Proceeding in a similar manner, operation entity204ccan be associated with refactoring operation208c. Refactoring operation208ccan involve the adaptation of a plurality of different objects (e.g., objects101-150) associated with object identifiers212in the operation entity204cin the changelist202. Upon completion of the refactoring operation208e, the changelist202can be updated to include operation entity204cas shown in changelist view202c. Operation entity204dcan be associated with refactoring operation208d. Refactoring operation208dcan involve the adaptation of a plurality of different objects (e.g., objects151-200) associated with object identifiers214in the operation entity204din the changelist202. Upon completion of the refactoring operation208d, the changelist202can be updated to include operation entity204das shown in changelist view202d. Operation entity204ecan be associated with refactoring operation208e. Refactoring operation208ecan involve the adaptation of a plurality of different objects (e.g., objects201-250) associated with object identifiers216in the operation entity204ein the changelist202. Upon completion of the refactoring operation208e, the changelist202can be updated to include operation entity204eas shown in changelist view202e.

According to the changelist view202e, the developer has completed five refactoring operations. The revised source code may be in an inconsistent state and additional adaptations of objects may be needed in order to stabilize the revised source code base. The developer can attempt an additional refactoring operation (e.g., refactoring operation2080in order to place the source code in a state for subsequent check-in.

In some implementations, refactoring operation208fmay result in a less than optimal adaptation of additional software objects (e.g., objects251-300associated with object entities218included in operation entity204fassociated with refactoring operation2080. The developer may choose to revert the refactoring operation208f. As described previously, if a changelist did not include operation entities, the developer would either revert or discard all refactoring operations208a-for revert every object (e.g., objects1-300) adapted by the refactoring operations208a-f. However, using operation entities in a changelist as shown inFIG. 2A, the developer can revert the single refactoring operation208fby reverting objects251-300, associated with object identifiers218.

Referring toFIG. 2B, an exemplar reversion of the changelist202ofFIG. 2Ain accordance with implementations of the present disclosure is shown. Objects251-300associated with object identifiers218can return to their previous state, which was their state prior to the source code check-out as objects251-300were not adapted by any previous refactoring operations. The source code will revert to the state it was in after performing refactoring operation208eand before performing refactoring operation208f.

For example, a developer can check-in or revert all objects adapted by the same refactoring operation (e.g., all objects whose associated object identifiers are included in an operation entity associated with the refactoring operation). Additionally, a developer can check-in or revert additional objects if they can be reached directly or indirectly via the objects that belong to the same refactoring operation.

As described with reference toFIG. 2A, the developer can revert refactoring operation208f. Changelist view202fcan revert to changelist view202e. Refactoring operation208ecan be the last refactoring operation performed as indicated by the associated operation entity204ein the changelist202by changelist view202e.

In some implementations, a developer may choose to revert a refactoring operation in a series of refactoring operations where the selected refactoring operation is not the last refactoring operation performed. For example, the selected refactoring operation may have occurred one or more refactoring operations before the last refactoring operation. In some implementations, a refactoring operation may adapt an object adapted by a previous refactoring operation. In some implementations, a developer may choose to revert a particular object. In order to revert a particular object, additional objects and refactoring operations may also need to be reverted. In these implementations, it may be necessary to determine a subset of operations and objects included in a changelist for reversion.

Referring toFIG. 3, a flowchart illustrates exemplar steps300that can be executed in accordance with implementations of the present disclosure is shown. In some implementations, reverting a refactoring operation can involve reverting a plurality of objects and additional refactoring operations. For example, a developer can check-in or revert all objects adapted by the same refactoring operation (e.g., all objects whose associated object identifiers are included in an operation entity associated with the refactoring operation). Additionally, a developer can check-in or revert additional objects if they can be reached directly or indirectly via the objects that belong to the same refactoring operation. For example, a subset of objects can be related directly or indirectly to a given set of operations. A direct relationship of an object to an operation can be defined as an object belonging to at least one refactoring operation in a set of refactoring operations. An indirect relationship of an object to an operation can be defined as a chain of one or more objects related to another object that is directly related to at least one refactoring operation in a set of refactoring operations.

The exemplar steps300can partition objects in a changelist into a plurality of independent partitions. One partition can include objects to revert, while another partition can include objects not to revert, for example.

In step302, a changelist is generated. For example, a developer can perform a plurality of refactoring operations to generate a changelist202as shown inFIG. 2A. In step304, it is determined whether the developer would like to revert an object or an operation. If the developer chooses to revert an object or operation, an object set is initialized to include an initial set of objects in step306, on which initial set of objects transitive closure calculations can be executed. For example, if a developer chooses to revert a particular refactoring operation, the object set can include the object identifiers included in the operation entity associated with the particular refactoring operation. The object identifiers identify the objects to be reverted. In another example, if a developer chooses to revert an object, the object set can include the associated object identifier for the object.

In step308, an operation set is initialized to include an initial set of operations. If a developer chooses to revert a refactoring operation, the operation set can include the selected refactoring operation. Additionally, the operation set can include all operations that adapt one or more objects in the initialized object set. For example, a refactoring operation has associated with it an operation entity in the changelist. The operation entity can include object identifiers associated with objects adapted by the operation. The operation set can include all operations associated with operation entities in the changelist that include at least one of the object identifiers in the object set.

In step310, the operations in the operation set are checked against the object set. If any operation in the operation set includes one or more objects that are not part of the object set, the object(s) are added to the object set in step314. If any operation in the operation set does not include objects that are not part of the object set, a reversion is executed on the object set and the operation set in step318. The object set can include the transitive closure for all objects in the object set. The SCM application can revert the objects in the object set to the object state prior to any refactoring operations (e.g., the object is returned to its state prior to the source code check-out, reflective of the prior source code check-in).

In step320, the objects in the object set are checked against the operation set. If any object in the object set is included in an operation not included in the operation set, the operation is added to the operation set in step322. The process continues back to step310to recheck the operations in the operation set against the object set. If any object in the object set is not included in an operation that is not part of the operation set, a reversion is executed on the object set and the operation set in step318. The object set can include the transitive closure for all objects in the object set. The SCM application can revert the objects in the object set to the object state prior to any refactoring operations (e.g., the object is returned to its state prior to the source code check-out, reflective of the prior source code check-in) by reverting the entire transitive closure for each object.

Referring toFIG. 4A, a first exemplar table400including refactoring operations402and corresponding objects404is shown. In the example ofFIG. 4A, a developer has chosen to revert operation402d. Using the exemplar steps300inFIG. 3, the SCM application can determine the objects and operations to revert. The table400can include two partitions410,412. Partition410can include the objects and operations to revert. Partition412can include the objects and operations that do not need reverting.

FIG. 4Bprovides an exemplar object set406and an exemplar operation set408based on an exemplar reversion to the operation402dofFIG. 4A. In the exemplar table400, operation402dadapts objects404band404c. To revert operation402d, the SCM application can also revert operation402cas operation402cadapts object404b, which is also adapted by operation402d. Additionally, the SCM application can revert operation402fas operation402fadapts object404c. Operations402a,402band402eare not reverted as they do not adapt objects404bor404c. Therefore, object set406includes objects404b,404c. The operation set408includes operations402c,402d,402f.

The SCM application, using the changelist and operation entities, and executing the steps300inFIG. 3can determine a subset of objects and operations to revert as shown in the exemplar table400inFIG. 4. The number of objects and operations to revert can be reduced compared to reverting all objects and operations in the implementations where the changelist does not include operation entities.

Referring toFIG. 5A, a second exemplar table500including refactoring operations502and corresponding objects504is shown. In the example inFIG. 5A, a developer has chosen to revert object504a. Using the exemplar steps300inFIG. 3, the SCM application can determine the objects and operations to revert. The table500can include two partitions510,512. Partition510can include the objects and operations to revert. Partition512can include the objects and operations that do not need reverting.

FIG. 5Bprovides an exemplar object set506and an exemplar operation set508based on an exemplar reversion to the object502aofFIG. 4A. In the exemplar table500, operation502aadapts objects504a,504e. To revert object504a, the SCM application can also revert operation502bas operation502badapts objects504a,504b. Additionally, the SCM application can revert operation502cas operation502cadapts objects504b,504c. The SCM application can revert operation502eas operation502eadapts objects504c,504d. Operation502dis not reverted as it does not adapt objects504a-e. Therefore, object set506includes objects504a-e. The operation set508includes operations502a,502b,502c, and502e.

The SCM application, using the changelist and operation entities, and executing the steps300inFIG. 3can determine a subset of objects and operations to revert as shown in the exemplar table500inFIG. 5. The number of objects and operations to revert can be reduced compared to reverting all objects and operations in the implementations where the changelist does not include operation entities.

As described inFIG. 3, the exemplar steps300can create an object set that can include the transitive closure for all objects in the object set. The SCM application can revert the objects in the object set to the object state prior to any refactoring operations (e.g., the object is returned to its state prior to the source code check-out, reflective of the prior source code check-in) by reverting the entire transitive closure for each object. As described, this can involve fewer object reversions compared to discarding all refactoring operations on all objects or reverting all objects in a changelist.

In some implementations, an SCM application can include an undo operation. As described above, an SCM application can maintain a version of each object in a source code file in the file system of the local client after each refactoring operation to adapt the object. The object versions can be saved in chronological order on the local client responsible for the check-out of the file. In some implementations, a changelist ID can be associated with each historical object version.

In some implementations, an SCM application can maintain a historical version of each object in a source code file in the file system of the local client after each adaptation of the object. A changelist can represent a sequential view of the object adaptations. If the changelist does not include an operation entity, each object adaptation is not associated with the operation that generated the adaptation. If a developer chooses a refactoring operation to revert, the developer can manually undo the changes to the objects adapted by the selected refactoring operation to return the objects to their state prior to the selected refactoring operation. If the changelist includes operation entities (e.g., changelist202inFIG. 2), each object adaptation is associated with the operation that generated the adaptation. If a developer chooses a refactoring operation to revert, the SCM application can automatically undo the changes to the objects adapted by the selected refactoring operation to return the objects to their state prior to the selected refactoring operation. The SCM application can use the operation entity to identify the object identifiers associated with the objects adapted by the selected refactoring operation in order to identify which stored objects to access on the local client. For example, the SCM application can automatically undo the changes to an object adapted by the selected refactoring operation object by reverting the object back to the historical version of the object stored on the local client prior to the selected refactoring operation.

Referring now toFIG. 6A, an exemplar changelist602that can be generated in accordance with implementations of the present disclosure is shown. A developer may perform a series of refactoring operations on an existing source code base. For example, a developer, using a local client (e.g., client108) can connect to an application server (e.g., application server102) by way of a network (e.g., network106). The developer can run a SCM application hosted on the application server (e.g., application server102). The developer can check-out one or more source code files that may include one or more objects for one or more refactoring operations (the SCM application can download copies of the source code files from the central repository (e.g., database104) to the local client (e.g., client108)). Upon initial check-out of one or more source code files, the SCM application can generate a changelist on the developer's local client (e.g., client108) in a local changelist file. The SCM application can maintain historical versions of the source code files and objects on the local client (e.g., client108).

In some implementations, the changelist can include an operation entity. The operation entity can include one or more object identifiers. The operation entity can be associated with a refactoring operation. Each object identifier can be associated with a software object adapted by the refactoring operation associated with the operation entity. In the example inFIG. 6A, a developer can perform a one or more refactoring operations608. The changelist602can include operation entities604a,604b. Refactoring operations608a,608bcan be associated with operation entities604a,604b, respectively. Fifty object identifiers606can be included in operation entity604a. Each object identifier606can be associated with a software object (e.g., object identifier606acan be associated with software object1) adapted by the refactoring operation608a.

For example, refactoring operation608acan involve the adaptation of fifty different objects (e.g., object1and an additional forty-nine objects, objects2-50) associated with object identifiers606in the operation entity604ain the changelist602. Upon completion of the refactoring operation608a, the changelist602can be updated to include operation entity604aas in changelist view602a. The SCM application can store the state of the objects1-50in the file system on the local client after performing refactoring operation608aand before performing refactoring operation608b. The developer can continue to perform refactoring operations (e.g., refactoring operations608b).

Operation entity604bcan be associated with refactoring operation608b. Ten object identifiers610can be included in operation entity604b. Each object identifier610can be associated with a software object (e.g., object identifier610acan be associated with software object1) adapted by the refactoring operation608b. Refactoring operation608bcan involve the adaptation of ten of the same objects (e.g., objects1-10) adapted by refactoring operation608a. The new adaptation of objects1-10(e.g., objects1′-10′) can be associated with object identifiers610in the operation entity604bin the changelist602. Upon completion of the refactoring operation608b, the changelist602can be updated to include operation entity604bas shown in changelist view602b. The SCM application can store the state of the objects1-10(e.g., objects1′-10′) in the file system of the local client after performing refactoring operation608b. A history view of the local file system can show the location in the file system of each version of the objects.

In some implementations, refactoring operation608bmay result in a less than optimal adaptation of the software objects (e.g., objects1-10associated with object entities610included in operation entity604bassociated with refactoring operation608b). The developer may choose to revert the last refactoring operation performed, refactoring operation608b. As described previously, if the changelist did not include operation entities, the developer would need to manually revert objects1-10(objects identified with object identifiers610) adapted by the selected reverted refactoring operation608bback to their saved state in the file system on the local client after refactoring operation604abut before refactoring operation604b. However, using operation entities in a changelist as shown inFIG. 6A, the SCM application can automatically revert the single refactoring operation608bby restoring objects1-10to their saved state in the file system on the local client after refactoring operation604abut before refactoring operation604b. In effect, the SCM application can perform an undo of the refactoring operation608b.

In the implementation described inFIG. 6A, if the SCM application did not have historical versions of the source code files and objects accessible from the file system on the local client in order to revert refactoring operation604b, the SCM application would need to determine the transitive closure for objects1-10. The SCM application can then perform the complete transitive closure for objects1-10restoring them to their states prior to the check-out of the source code for the refactoring operations608. When historical versions of the objects are available in the file system of the local client, the SCM application can undo the selected reverted refactoring operation, which essentially performs a partial transitive closure of the objects included in the reverted operation. The objects can be restored to a state prior to the reverted refactoring operation.

Referring toFIG. 6B, an exemplar reversion of the changelist602ofFIG. 6Ain accordance with implementations of the present disclosure is shown. As described with reference toFIG. 6A, the developer can revert refactoring operation608b. Changelist view602bcan revert to changelist view602a. Refactoring operation608acan be the last refactoring operation performed as indicated by the associated operation entity604ain the changelist602by changelist view602a.

Referring toFIG. 7A, a third exemplar table700including refactoring operations702and corresponding objects704is shown. In the example inFIG. 7A, a developer has chosen to revert operation702c. The table700can include two partitions710,712. Partition710can include the objects and operations to revert. Partition712can include the objects and operations that do not need reverting. In calculating the partial transitive closure for objects directly or indirectly adapted by refactoring operation704c, the SCM application, using a changelist and operation entities, can execute the steps300inFIG. 3. However, if historical versions of the objects are available to the SCM application from the file system of the local client that includes the changelist, the SCM application can calculate a partial transitive closure for objects. In the example inFIG. 7A, steps300are performed using operations702c-702f(the selected reverted refactoring operation and any subsequent operations). Operations702a,702bmay not be included in the execution of steps300.

FIG. 7Bprovides an exemplar object set706and an exemplar operation set708based on an exemplar reversion to the operation702cofFIG. 7A. In the exemplar table700, operation702cadapts object704aand object704b. In order to revert operation702c, the SCM application can also revert subsequent operation702das operation702dfurther adapts object704band adapts object704c. The SCM can also revert operation704f, which further adapts object704cand adapts object704d. Operation702eis not reverted as it does not adapt objects704a,704b,704cor704d. Therefore, object set706includes objects704a,704b,704cand704d. The operation set408includes operations702c,702d, and702f.

The SCM application can undo the refactoring operations included in the operation set708. The undo operation essentially performs a partial transitive closure of the objects included in the object set706. The objects in object set706can be restored to a state prior to the reverted refactoring operation (operation702c).

Referring toFIG. 8A, a fourth exemplar table800including refactoring operations802and corresponding objects804is shown. In the example inFIG. 8A, a developer has chosen to completely revert object804b. The table800can include two partitions810,812. Partition810can include the objects and operations to revert. Partition812can include the objects and operations that do not need reverting. In calculating the partial transitive closure for objects directly or indirectly adapted by refactoring operations that also adapt object804b, the SCM application, using a changelist and operation entities, can execute the steps300inFIG. 3. However, if historical versions of the objects are available to the SCM application from the file system of the local client that includes the changelist, the SCM application can calculate a partial transitive closure for objects. In the example inFIG. 8A, steps300are performed using operations802b-802eas object804bis not adapted by previous refactoring operation802a. Therefore, it is not necessary to revert operation802ain order to completely revert object804b. Operation802amay not be included in the execution of steps300.

FIG. 8Bprovides an exemplar object set806and an exemplar operation set808based on an exemplar reversion of object802binFIG. 8A. In the exemplar table800, operation802badapts object804band object804d. In order to revert object804b, the SCM application can also revert subsequent operation802cas operation802cfurther adapts object804band adapts object804cand object804e. The SCM can also revert operation804d, which further adapts object804d. Operation802eis not reverted as it does not adapt objects804b,804c,804dor804e. Therefore, object set806includes objects804b,804c,804dand804e. The operation set808includes operations802b,802c, and802d.

The SCM application can undo the refactoring operations included in the operation set808. The undo operation essentially performs a partial transitive closure of the objects included in the object set806. Since operation802adoes not adapt object804b, which was selected for a complete reversion, the undo operation results in the complete reversion of object804b(object804bis returned to the state prior to check-out of the source code and before any refactoring operations were performed). The objects in object set806can be restored to a state prior to operation802b(their state after operation802awas performed).

In some implementations, the SCM application can maintain a historical record of the differences between each chronological version of an object. The SCM application can recreate an object at a point time using the record of the changes made to the object from its previous versions to its current version at that point in time.

Referring now toFIG. 9, a schematic illustration of exemplar hardware components900that can be used to execute implementations of the present disclosure is provided. The system900can be used for the operations described in association with the method described inFIG. 3according to one implementation. For example, the system900may be included in the application server102. The system900includes a processor910, a memory920, a storage device930, and an input/output device940. Each of the components910,920,930, and940are interconnected using a system bus950. The processor910is capable of processing instructions for execution within the system900. In one implementation, the processor910is a single-threaded processor. In another implementation, the processor910is a multi-threaded processor. The processor910is capable of processing instructions stored in the memory920or on the storage device930to display graphical information for a user interface on the input/output device940.

The memory920stores information within the system900. In one implementation, the memory920is a computer-readable medium. In one implementation, the memory920is a volatile memory unit. In another implementation, the memory920is a non-volatile memory unit. The storage device930is capable of providing mass storage for the system900. In one implementation, the storage device930is a computer-readable medium. In various different implementations, the storage device930may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. The input/output device940provides input/output operations for the system900. In one implementation, the input/output device940includes a keyboard and/or pointing device. In another implementation, the input/output device940includes a display unit for displaying graphical user interfaces.