Determining which software component versions of an issue resolution are included in a version of a software development project at a particular time Number:7,437,722 from the United States Patent and Trademark Office (PTO) owispatent Systems and methods for automatically determining, for a version of a software developing project, which software component versions defined for an issue resolution at a particular time, for example, a time in the past, are included in the project version at the particular time. Such determination may include determining the software component versions included in an issue resolution at a particular time, and, for each determined version, determining whether the version is included in the project version. The software components that should be propagated to other versions of a software development project so that these versions have a complete issue resolution may be determined. Further, differences between software project versions, from an issue resolution prospective, may be determined.<H development, Determining, Determining, whi, 7437722.html, Patent, pto, 7437722

Title: Determining which software component versions of an issue resolution are included in a version of a software development project at a particular time

Abstract: Systems and methods for automatically determining, for a version of a software developing project, which software component versions defined for an issue resolution at a particular time, for example, a time in the past, are included in the project version at the particular time. Such determination may include determining the software component versions included in an issue resolution at a particular time, and, for each determined version, determining whether the version is included in the project version. The software components that should be propagated to other versions of a software development project so that these versions have a complete issue resolution may be determined. Further, differences between software project versions, from an issue resolution prospective, may be determined.

Patent Number: 7,437,722 Issued on 10/14/2008 to Poole

Inventors: Poole; Damon B. (Brookline, MA)
Assignee: Accurev, Inc. (Lexington, MA)

Appl. No.: 10/894,697

Filed: July 19, 2004

Current U.S. Class: 717/170

Current International Class: G06F 9/45 (20060101)

Field of Search: 717/170 707/203

References Cited [Referenced By]

U.S. Patent Documents


4809170	February 1989	Leblang et al.
5600834	February 1997	Howard
5649200	July 1997	Leblang et al.
6216140	April 2001	Kramer
6256773	July 2001	Bowman-Amuah
6557012	April 2003	Arun et al.
6978281	December 2005	Kruy et al.
7251655	July 2007	Kaler et al.
7289973	October 2007	Kiessig et al.
2004/0056903	March 2004	Sakai et al.
2006/0031811	February 2006	Ernst et al.

Primary Examiner: Chavis; John
Attorney, Agent or Firm: Wolf, Greenfield & Sacks, P.C.

Claims

What is claimed is:

1. For a software development project represented by a hierarchy of versions of the software development project, each version comprising a set of versions of software components, a method of determining whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project, the method comprising acts of: (A) determining the one or more software component versions included in the issue resolution for the software development project at the first time by accessing a data structure representing a history of changes to the issue resolution, the issue resolution comprising at least one software component which comprises functional software code for a software product; and (B) for each software component version determined in act (A), determining whether the software component version was included in the first version of the software development project at the first time.

2. The method of claim 1, wherein the act (B) comprises accessing a data structure representing a history of changes to at least the first version of the software development project.

3. The method of claim 1, wherein the first time is a past time.

4. The method of claim 1, wherein the software component is a file.

5. The method of claim 1, wherein act (A) comprises accessing a plurality of entries in the data structure, each entry including one or more values indicating a version of a software component, one or more values corresponding to a particular time and one or more values indicating whether the version of the software component was included in the issue resolution at the particular time.

6. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a system including a processor configured for determining whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project, the system comprising: an issue resolution components generator to receive one or more inputs specifying an issue resolution for the software development project and a value corresponding to the first time, to determine the one or more software components versions included in the issue resolution at the first time by accessing a data structure representing a history of changes to the issue resolution, the issue resolution comprising at least one software component which comprises functional software code for a software product, and to output the one determined software component versions; and a version checking module to receive one or more inputs specifying the one or more determined software component versions and a value corresponding to the first time, to determine, for each of the one or more determined software, component versions, whether the determined version was included in the first version of the software development project at the first time.

7. The system of claim 6, wherein the version checking module is operative to access a data structure representing a history of changes to the first version to determine, for each of the one or more determined software component versions, whether the determined version was included in the first project version at the first time.

8. The system of claim 7, further comprising: the data structure representing the history of changes to at least the first version of the software development project.

9. The system of claim 6, wherein the first time is a past time.

10. The system of claim 6, wherein the software component is a file.

11. The system of claim 6, wherein, to determine the one or more software components versions included in the issue resolution at the first time, the issue resolution components generator is operative to access a plurality of entries in the data structure, each entry including one or more values indicating a version of a software component, a one or more values corresponding to a particular time and one or more values indicating whether the version of the software component was included in the issue resolution at the particular time.

12. The system of claim 6, further comprising: the data structure representing the history of changes to the issue resolution.

13. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a system including a processor configured for determining whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project, the system comprising: means for determining the one or more software component versions included in the issue resolution of the software development project at the first time by accessing a data structure representing a history of changes to the issue resolution, the issue resolution comprising at least one software component which comprises functional software code for a software product; and a version checking module to receive one or more inputs specifying the one or more determined software component versions and a value corresponding to the first time, to determine, for each of the one or more determined software component versions, whether the determined version was included in the first version of the software development project at the first time.

14. For a software development project represented by a hierarchy of versions of the software development project, each version comprising a set of versions of software components, a computer-readable medium having computer-readable signals stored thereon that define instructions that, as a result of being executed by a computer, control the computer to perform a method of determining whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project, the method comprising acts of: (A) determining the one or more software component versions included in the issue resolution of the software development project at the first time by accessing a data structure representing a history of changes to the issue resolution, the issue resolution comprising at least one software component which comprises functional software code for a software product; and (B) for each software component version determined in act (A), determining whether the software component version was included in the first version of the software development project at the first time.

15. A computer-readable medium having stored thereon a plurality of computer-readable signals defining a data structure for use in conjunction with a configuration management software application for managing a software development project including a plurality of software components, the data structure representing a history of changes to an issue resolution, the issue resolution including one or more software components representing a change to the software development project, wherein the data structure comprises: a plurality of entries, each entry including one or more values corresponding to a particular time, one or more values indicating a version of a software component and one or more values indicating whether the version of the software component was included in the issue resolution of the software development project at the particular time, the issue resolution comprising at least one software component which comprises functional software code for a software product.

16. The computer-readable medium of claim 15, wherein, for one or more entries of the data structure, the one or more values corresponding to a particular time is a transaction number.

17. The computer-readable medium of claim 15, wherein, for one or more entries of the data structure, the one or more values indicating a version of a software component include a value indicating a version of the software development project and a value representing an edition of the software component for the software development project version.

18. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a method of modifying the contents of an issue resolution representing a change to the software development project, the method comprising acts of: (A) receiving, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution of the software development project, the issue resolution comprising at least one software component which comprises functional software code for a software product; and (B) recording an entry in a data structure representing a history of changes to at least the first issue resolution, the entry including one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

19. The method of claim 18, wherein the act (B) comprises recording, for one or more entries of the data structure, a transaction number as one of the one or more values corresponding to a first time.

20. The method of claim 18, wherein, the act (B) comprises recording, for one or more entries of the data structure, a value indicating a version of the software development project and a value representing an edition of the software component for the software development project version as part of the one or more values indicating a version of a software component.

21. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a system for modifying the contents of an issue resolution representing a change to the software development project, the system comprising: a user interface to receive, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution of the software development project, the first issue resolution comprising at least one software component which comprises functional software code for a software product; and an issue resolution engine to record an entry in a data structure representing a history of changes to at least the first issue resolution, the entry including one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

22. The system of claim 21, wherein the issue resolution engine is operative to record, for one or more entries of the data structure, a transaction number as one of the one or more values corresponding to a particular time is.

23. The system of claim 21, wherein the issue resolution engine is operative to record, for one or more entries of the data structure, a value indicating a version of the software development project and a value representing an edition of the software component for the software development project version as part of the one or more values indicating a version of a software component.

24. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a system for modifying the contents of an issue resolution representing a change to the software development project, the system comprising: a user interface to receive, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution of the software development project, the first issue resolution comprising at least one software component which comprises functional software code for a software product; and means for recording an entry in a data structure representing a history of changes to at least the first issue resolution, the entry including one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

25. For a software development project represented by a hierarchy of versions of the software project, each version comprising a set of versions of software components, a computer-readable medium having computer-readable signals stored thereon that define instructions that, as a result of being executed by a computer, control the computer to perform a method of modifying the contents of an issue resolution representing a change to the software development project, the method comprising acts of: (A) receiving, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution of the software development project, the first issue resolution comprising at least one software component which comprises functional software code for a software product; and (B) recording an entry in a data structure representing a history of changes to at least the first issue resolution, the entry including one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

Description

RELATED APPLICATIONS

Commonly-owned U.S. patent application titled SYSTEMS AND METHODS FOR DETERMINING THE SOFTWARE COMPONENTS INCLUDED IN A VIEW OF A SOFTWARE DEVELOPMENT PROJECT AT A PARTICULAR TIME by Damon B. Poole, filed on even date herewith under Ser. No. 10/894,964 (hereinafter, the Poole application) is hereby incorporated by reference in its entirety.

BACKGROUND

Developing software applications and products often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a "software development effort" or "development effort," and the body of work (e.g., one or more software applications and/or products) being developed by the effort is referred to as a "software development project," "development project" or "project." At any given time, as part of a software development effort, multiple developers may be working on different components of a software development project and/or different versions of these components (e.g., for different users or situations). Managing the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). CM software applications (i.e., programs) assist developers and project managers in the management of a software development project, including maintaining coherency between different components and versions.

A software development effort typically involves adding or improving functionality (i.e., adding features) to a product, and fixing functionality that is not working properly (i.e., fixing defects or "bugs"). Typically, one or more fixes, features or combinations thereof (i.e., development items) are grouped together as a development unit called an "issue." At a minimum, an issue defines one or more development items, and often includes other information. Issues are often tracked as part of a development effort, and tracking information may be added to an issue description, including information indicating that the issue has been resolved. Because of the often significant numbers of issues involved in a development effort, development efforts typically employ an issue tracking system to track the progress of the resolution of each issue.

A primitive issue tracking system may involve the creation of a list of issues on paper, where a description of each issue is written down. Notes may be taken throughout the progress of resolving the issue, and the issue may be checked off when it has been resolved. More often, tracking systems are implemented using a computer system, for example, as part of a CM application. Such computerized tracking systems may provide a unique identifier (e.g., a serial number) for each issue, and provide data fields that enable a user (e.g., a developer, supervisor or project team leader) to track the progress of the issue's resolution.

During the resolution of an issue, the one or more software components (e.g., objects, records, programs, files, directories, etc.) that need to be modified or added to resolve the issue is/are determined. Some issue tracking systems enable an association to be created and maintained between an issue and the one or more software components needed to resolve the issue. More specifically, an association can be created and maintained between an issue and the versions of the one or more software components needed to resolve the issue. As used herein, an "issue resolution" or "resolution" is an abstraction (e.g., a software abstraction such as an object, record, variable or table) defining an association between a an issue and one or more software components and versions thereof that provide a solution to the issue. For example, an issue is created describing a bug, and it is determined that a first version of a file is causing the bug. A second version of the file that resolves the problem is developed, and an issue resolution created that associates the second version of the file with the resolution of the issue.

As described above, a software development effort often involves multiple developers working concurrently on different versions of different software components. Some CM applications provide each developer a "workspace" (defined below) in which the developer can add, modify and delete components of the development project pertinent to the developer's objective. Further, a CM application may maintain one or more versions of the project itself (e.g., branches or streams--defined below), and a developer's workspace may be configured to enable the developer to make changes to a particular version of the project. As used herein, a "version" of a software development project (or other software entity) is a set of software components of the project, and for each software component, a version thereof. It should be appreciated that different versions of a software project (or other type of software entity) may have the same content (e.g., may include a same set of software component versions) or different content. A developer's workspace may be considered a version of the project. It is often desirable to propagate modifications made in a developer's workspace (e.g., an addition, change or deletion of one or more software objects) to other versions of the project, including other workspaces. CM applications often are configured to provide such propagation.

In addition to providing the propagation of modified software components, some CM applications provide an issue tracking system that enables a user to record that an issue resolution has been propagated to one or more versions of the project. For example, the user can make an entry in the tracking system that indicates that a particular issue resolution has been propagated to a particular version of the project. To determine that an issue resolution has been propagated to a version of the project, the user determines the software components and versions associated with the issue resolution, for example, by looking up the issue resolution in the issue tracking system. Then the user determines whether all of the versions of the software components have been propagated to the version of the project, for example, by looking up the list of software components and their associated versions currently in the project.

Thus, known issue tracking systems require a user to manual determine whether an issue resolution has been propagated to particular version of a project, for example, by looking up information on the system. Further, the user must manually record the propagation of the issue resolution. Such manual determination is time-consuming and susceptible to human error.

Some known issue tracking systems allow the definition of an issue resolution to be altered after the versions of the software components defined by the issue resolution have been propagated to one or more versions of a project. Consider the following example. An issue resolution specifies a second version of a file, which resides in a first branch of a project. The second version of the file is then propagated to a second branch of the project, and a user creates a record indicating that the issue resolution is included in (i.e., has been propagated to) the second branch. Then, after the issue resolution has been propagated, the developer realizes that there is another change that needs to be made to the file. The developer then creates a third version of the file in the first branch and alters the definition of the issue resolution to include the third version of the file, replacing the second version. Another example is if the developer adds another file to the issue resolution.

If the record is not updated to reflect that the issue resolution (in its current form) has not been propagated to the branch, then the propagation record is now inaccurate, as the second branch does not actually include the issue resolution. Rather, the second branch includes the earlier second version of the file. Known systems do not have the ability to automatically detect this scenario and update the record, such that user must manually do so.

Thus, known issue tracking systems are susceptible to human error resulting in the maintenance of an inaccurate record of issue propagation. As a result, a customer may be provided a version of a software product that allegedly includes a resolution to an issue (e.g., a bug fix or a new feature), but, in fact, does not include the resolution.

Another shortcoming of known issue tracking systems is that no electronic record is maintained of the history of changes made to an issue resolution (i.e., changes to the set of software component versions included therein). Thus, known systems are limited to maintaining only the current state of an issue resolution, such that the state of an issue resolution (e.g., the software components included therein) at a time in the past cannot be determined automatically.

SUMMARY

In an embodiment of the invention, a method is provided for a software development project represented by a hierarchy of versions of the software development project, each version including a set of versions of software components. It is determined determining whether the one or more software component versions included in an issue resolution at a first time are also included in a first version of the software development project at the first time. The issue resolution represents a change to the software development project. The one or more software component versions included in the issue resolution at a first time are determined by accessing a data structure representing a history of changes to the issue resolution. For each determined software component, it is determined whether the software component version was included in the first version at the first time.

In another embodiment of the invention, a computer-readable medium is provided that stores computer-readable signals defining instructions that, as a result of being executed by a computer, instruct the computer to perform the method described in the preceding paragraph.

In another embodiment, a system is provided for a software development project represented by a hierarchy of versions of the software project, each version including a set of versions of software components. The system determines whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project. The system includes an issue resolution components generator to receive one or more inputs specifying an issue resolution and a value corresponding to a first time. The issue resolution components generator determines the one or more software components versions included in the issue resolution at the first time by accessing a data structure representing a history of changes to the issue resolution, and outputs the one determined software component versions. The system also includes a version checking module to receive one or more inputs specifying the one or more determined software component versions and a value corresponding to the first time. The version checking module determines, for each of the one or more determined software component versions, whether the determined version was included in the first project version at the first time.

In yet another embodiment, a system is provided for a software development project represented by a hierarchy of versions of the software project, each version including a set of versions of software components. The system determines whether one or more software component versions included in an issue resolution at a first time are included in a first version of the software development project at the first time, the issue resolution representing a change to the software development project. The system includes means for determining the one or more software component versions included in the issue resolution at a first time by accessing a data structure representing a history of changes to the issue resolution The system also includes a version checking module to receive one or more inputs specifying the one or more determined software component versions and a value corresponding to the first time. The version checking module determines, for each of the one or more determined software component versions, whether the determined version was included in the first project version at the first time.

In another embodiment, provided is a computer-readable medium having stored thereon a plurality of computer-readable signals. The signals define a data structure for use in conjunction with a configuration management software application for managing a software development project including a plurality of software components. The data structure represents a history of changes to an issue resolution, the issue resolution including one or more software components representing a change to the software development project. The data structure includes a plurality of entries. Each entry includes one or more values corresponding to a particular time, one or more values indicating a version of a software component and one or more values indicating whether the version of the software component was included in the issue resolution at the particular time.

In another embodiment, a method is provided for a software development project represented by a hierarchy of versions of the software project, each version including a set of versions of software components. The contents of an issue resolution representing a change to the software development project are modified. At a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution are received. An entry is recorded in a data structure representing a history of changes to at least the first issue resolution. The entry includes one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

In another embodiment of the invention, a computer-readable medium is provided that stores computer-readable signals defining instructions that, as a result of being executed by a computer, instruct the computer to perform the method described in the preceding paragraph.

In yet another embodiment, a system is provided for a software development project represented by a hierarchy of versions of the software project, each version including a set of versions of software components. The system modifies the contents of an issue resolution representing a change to the software development project. The system includes a user interface to receive, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution. The system also includes an issue resolution engine to record an entry in a data structure representing a history of changes to at least the first issue resolution. The entry includes one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

In another embodiment, a system is provided for a software development project represented by a hierarchy of versions of the software project, each version including a set of versions of software components. The system modifies the contents of an issue resolution representing a change to the software development project. The system includes a user interface to receive, at a first time, one or more inputs specifying whether to include a first software component version in a first issue resolution. The system also includes means for recording an entry in a data structure representing a history of changes to at least the first issue resolution. The entry including one or more values corresponding to the first time, and one or more values specifying whether to include the first software component in the first issue resolution at the first time.

Other advantages, novel features, and objects of the invention, and aspects and embodiments thereof, will become apparent from the following detailed description of the invention, including aspects and embodiments thereof, when considered in conjunction with the accompanying drawings, which are schematic and which are not intended to be drawn to scale. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a single numeral. For purposes of clarity, not every component is labeled in every figure, nor is every component of each embodiment or aspect of the invention shown where illustration is not necessary to allow those of ordinary skill in the art to understand the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example of a system for modifying an issue resolution and/or determining the software components of an issue resolution that are included in a stream at a particular time;

FIG. 2 is a diagram illustrating an example of a directory hierarchy;

FIG. 3 is a screen shot illustrating an example of a GUI display that includes a representation of a stream hierarchy;

FIG. 4 is a diagram illustrating an example of an ancestry graph of a software component, including virtual versions of the software component;

FIG. 5 is a diagram illustrating an example of an ancestry graph of a software component, not including virtual versions;

FIG. 6 is a flowchart illustrating an example of a method of adding or removing a version of a software component to/from and issue resolution;

FIG. 7 illustrates an example of a GUI display for associating/disassociating versions of software components with/from an issue resolution;

FIG. 8 is a block diagram illustrating an example of a historical issue resolution data structure;

FIG. 9 is a block diagram illustrating an example of a historical stream in-progress data structure;

FIG. 10 is a block diagram illustrating an example of a historical virtual version mapping data structure;

FIG. 11 is a block diagram illustrating an example of a version ancestry data structure;

FIG. 12 is a block diagram illustrating an example of a historical stream ancestry chain data structure;

FIG. 13 is a flowchart illustrating an example of a method of determining the software component versions of an issue resolution included in a stream at a particular time;

FIG. 14 is a flowchart illustrating an example of a method of determining the software component versions included in an issue resolution at a particular time;

FIG. 15 is a flowchart illustrating an example of a method of determining whether software component versions are included in a queried stream at a queried time;

FIG. 16 is a flowchart illustrating an example of a method of determining a stream ancestry chain of a stream at a queried time;

FIG. 17 is a flowchart illustrating an example of a method of determining a stream of a stream ancestry chain in which a component was in progress at a particular time;

FIG. 18 is a flowchart illustrating an example of a method of determining a version of a software component included in a stream at a particular time;

FIG. 19 is a flowchart illustrating an example of a method of determining whether a version of a software component that is included in an issue resolution at a particular time was comprised in the version of the software component included in a stream at the particular time;

FIG. 20 is a block diagram illustrating an example of a system for modifying an issue resolution and for determining which software component versions of an issue resolution are included in a stream at a particular time;

FIG. 21 is a block diagram illustrating an example of computer system that may be used to implement some embodiments of the invention; and

FIG. 22 is a block diagram illustrating an example embodiment of a memory system for the computer system of FIG. 21.

DEFINITIONS

The following terms have the following meanings in this application. All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.

As used herein, a "plurality" means two or more.

As used herein, a "software component" is a component of a larger software entity, for example, an application (program), a development project, a product, another software component, another type of software entity or any combination thereof. A software component may be, for example, a program, a file, a directory, a directory element, an object, a record, a table, another type of software component or any combination thereof. As used herein, a "directory element" is a directory or a file.

As used herein, a "file hierarchy" is a logical hierarchy defining an organization of files. FIG. 2, described in more detail below, illustrates an example of a directory hierarchy. A file hierarchy includes at least a "root directory" at a highest level of the hierarchy. The root directory may include, at a second level in the hierarchy, one or more directory elements. As used herein, a "directory element" is an element of a directory, and may be any of a variety of types of software components (e.g., a file or directory). As used herein, a "directory," including the root directory and any of its sub-directories, is a directory element (e.g., of a file hierarchy) that includes one or more other directory elements, e.g., files and/or directories. As used herein, a "child element" or "child" of a directory (e.g., the root directory or any of its sub-directories) is an element included within the directory at a level immediately below the level of the hierarchy, whereas any element included within the directory, regardless of level, is referred to as a "descendant element" or "descendant" of the directory. Conversely, a directory is referred to herein as a "parent directory" or "parent" of any elements included in the directory at the level immediately below the directory, and is referred to as an "ancestor element" or "ancestor" of any included element, regardless of hierarchy level. Conceptually, a file hierarchy is not limited to a maximum number of levels, although in practice, this number may be limited by computational and storage capabilities of the system on which the file hierarchy is implemented.

As used herein, a "stream" is a software abstraction representing a version of a software development project (or other type of software entity) and including a set of software components. As used herein, a "set" of items may include one or more of such items. For example, a set of software components may include one or more software components.

As will be described in more detail below, a stream may be part of a stream hierarchy. As used herein, a "stream hierarchy" is a logical hierarchy of streams defining relationships between streams. FIG. 3, described in more detail below, illustrates an example of a stream hierarchy. A stream hierarchy includes at least one stream, the "source stream", which is at a highest level of the hierarchy, and is the stream from which the other streams of the hierarchy are ultimately derived. A stream having one or more children is a "parent stream" or "parent" of each child stream. A parent stream, including the source stream, may have one or more "children" or "child streams," that each inherit one or more properties of the parent stream and its ancestors. For example, as will be described in more detail below, a child stream may be configured to inherit one or more software components and properties thereof from its parent. As will be explained in more detail below, although a child stream typically is derived directly (i.e., created from) its parent stream, this is not always the case, as a stream's relative position within the hierarchy may change over time. As a result, a child stream may have a parent from which the child was not derived.

As used herein, a "workspace" is a type of stream in which a user (e.g., a developer) can make changes to the content of a software entity (e.g., a software development project). Workspaces may be limited to being at the bottom of a stream hierarchy and any stream ancestry chains (described below) determined for the stream hierarchy. In some embodiments, workspaces are configured such that they cannot have child streams; i.e., so that they cannot be a parent stream. Thus, in some embodiments, as will be described in more detail below, changes to a software entity are made only in workspaces, and then propagated to other streams.

As used herein, a "user interface" is an application or part of an application (i.e., a set of computer-readable instructions) that enables a user to interface with an application during execution of the application. A user interface may include code defining how an application outputs information to a user during execution of the application, for example, visually through a computer screen or other means, audibly through a speaker of other means, and manually through a game controller or other means. Such user interface also may include code defining how a user may input information during execution of the application, for example, audibly using a microphone or manually using a keyboard, mouse, game controller, track ball, touch screen or other means.

As used herein, a "visual user interface" is the portion of the user interface that defines how information is visually presented (i.e., displayed) to the user, and defines how the user can navigate the visual presentation (i.e., display) of information and input information in the context of the visual presentation. During execution of the application, the visual interface controls the visual presentation of information and enables the user to navigate the visual presentation and enter information in the context of the visual presentation. Types of visual user interfaces range from command-driven interfaces, where users type commands, menu-driven interfaces, where users select information from menus, and combinations thereof, to GUIs, which typically take more advantage of a computer's graphics capabilities, are more flexible, intuitive and easy to navigate and have a more appealing "look-and-feel" than command-driven and menu-driven visual user interfaces.

As used herein, the visual presentation of information presented by a user interface, visual user interface or GUI is referred to as a "user interface display", "visual user interface display" or a "GUI display", respectively.

As used herein, an "application programming interface" or "API" is a set of one or more computer-readable instructions that provide access to one or more other sets of computer-readable instructions that define functions, so that such functions can be configured to be executed on a computer in conjunction with an application program. An API may be considered the "glue" between application programs and a particular computer environment or platform (e.g., any of those discussed below) and may enable a programmer to program applications to run on one or more particular computer platforms or in one or more particular computer environments.

As used herein, a "data structure" is an ordered arrangement of data defined by computer-readable signals recorded by a program for use by that or another program(s). These signals may be read by a computer system, stored on a medium associated with a computer system (e.g., in a memory, on a disk, etc.) and may be transmitted to one or more other computer systems over one or more communications media such as, for example, one or more segments of a network.

The indefinite articles "a" and "an," as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean "at least one."

The phrase "and/or," as used herein in the specification and in the claims, should be understood to mean "either or both" of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Other elements may optionally be present other than the elements specifically identified by the "and/or" clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to "A and/or B", when used in conjunction with open-ended language such as "comprising" can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

When separating items in a list, "and/or" shall be interpreted as being inclusive, i.e., the inclusion of at least one, and potentially including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as "only one of" or "exactly one of," or, when used in the claims, "consisting of," will refer to the inclusion of exactly one element of a number or list of elements. In general, the term "or" as used herein shall only be interpreted as indicating exclusive alternatives (i.e. "one or the other but not both") when preceded by terms of exclusivity, such as "either," "one of," "only one of," or "exactly one of." "Consisting essentially of", when used in the claims, shall have its ordinary meaning as used in the field of patent law.

As used herein in the specification and in the claims, the phrase "at least one," in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase "at least one" refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, "at least one of A and B" (or, equivalently, "at least one of A or B," or, equivalently "at least one of A and/or B") can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

As used herein, whether in the written description or the claims, the terms "comprising", "including", "carrying", "having", "containing", "involving", and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of", respectively, shall be closed or semi-closed transitional phrases, as set forth, with respect to claims, in the United States Patent Office Manual of Patent Examining Procedures (Original Eighth Edition, August 2001), Section 2111.03.

DETAILED DESCRIPTION

Described herein are systems and methods for automatically determining for a stream (or other type of version of a project, e.g., a branch), which software component versions defined for an issue resolution at a particular time (e.g., a current time or a time in the past) are included in the stream. Such determination may include determining the software component versions included in an issue resolution at a particular time, and, for each determined version, determining whether the version is included in the stream.

In some embodiments, the definition of an issue resolution is changed over time, even after the issue resolution has been propagated to a stream. In such embodiments, the above determinations still may be made accurately for the stream.

From the above determinations, software component versions that should be propagated to a stream so that the stream has a complete issue resolution may be determined. Further, differences between streams (e.g., from an issue resolution perspective) may be determined.

Any of the following data structures and combinations thereof may be provided in embodiments of the invention to assist in the aforementioned determinations: one or more data structures representing a history of changes to an issue resolution (e.g., the component versions defined therefor); one or more data structures that represent a history of changes to the component versions included in streams; and one or more data structures (e.g., historical and non-historical) that represents relationships between versions of software components.

Some embodiments described below do not require the recording (e.g., at the explicit instruction of a user) of the fact that an issue resolution as a whole or in part (i.e., less than all of the component versions thereof) was included or not included in a particular stream at a particular time. Rather, in such embodiments, a determination may be made "on the fly" (i.e., dynamically), for example, by accessing one or more of the aforementioned data structures, as is described below in more detail.

A user interface may be provided that enables a user (e.g., a developer, project leader, team leader, etc.) to enter an issue, and to assign one or more software components and versions thereof to a resolution of the issue. The user interface may enable a user to dynamically configure an issue tracking system (e.g., dynamically configure the issue tracking system after it has been deployed on a customer site).

Although several embodiments discussed herein are described primarily in reference to files, it should be appreciated that the invention is not limited thereto. Embodiments of the invention may be applied to or implemented using any of a variety of types of software components such as, for example, any of those described above. Further, although several embodiments described herein are described primarily in reference to a software development project, it should be appreciated that the invention is not limited thereto. Embodiments of the invention may be applied to or implemented using any of a variety of types of software entities such as, for example, any of those described above.

Further, although some embodiments discussed herein are discussed primarily in relation to streams, the invention is not so limited. The methods and systems described herein may be applied to any type of version of a software development project or other entity.

In some embodiments of the invention, every transaction affecting a software entity (e.g., a software development project) is recorded, for example, in a database. A transactions may include: a creation, modification or deletion of any of a software entity, a software component or a stream; a promotion of a software component from one stream to another, an updating of a stream; a change of location of a stream within a stream hierarchy; a change of location of a software component within a file hierarchy; the creation, modification or deletion of an issue and/or an issue resolution; the creation, modification or deletion of any information (e.g., meta data) relating to any of the foregoing; any other type of transaction; and any combination of the foregoing.

Each transaction may be assigned a unique transaction identifier, for example a number. Such an identifier may be referred to herein as a "transaction number." A time (e.g., a standard time) at which the transaction occurred may be associated with each transaction, such that each transaction corresponds to a time. The association of a transaction and a time may be stored as an entry in a data structure. Such a data structure may be referred to herein as "transaction data structure," and may include a plurality of entries, each entry representing a transaction and including a transaction number, a time and possibly other information (e.g., a description of the transaction).

Each transaction may result in a new entry being created in one or more other data structures as well, for example, any of data structures 800-1200. described below in more detail. Each new entry may include the transaction number associated with the transaction. The transaction data structure and the other data structures together may form a historical project development database, from which the state of various properties (e.g., content and other parameters) of a development project at any time during the life of the project may be determined and recreated. Specific examples of this ability to determine and recreate a past state of one or more parameters of a project is discussed in more detail below.

The function and advantage of these and other embodiments of the present invention will be more fully understood from the examples described below. The following examples are intended to facilitate an understanding of the invention and to illustrate the benefits of the present invention, but do not exemplify the full scope of the invention.

EXAMPLES

FIG. 1 is a block diagram illustrating an example of a system 100 for associating/disassociating software component versions (also referred to herein as "component versions") with an issue resolution and for determining which component versions of an issue resolution are included within a stream at a particular time. System 100 may include any of issue tracking engines 102 and a historical development project database 106, which may include one or more data structures 108. The issue tracking engine 102 may be configured to receive one or more user inputs 114, for example, user inputs specifying one or more of any of the following; streams, software components, versions of software components, issues, issue resolutions, transaction numbers, time, other inputs, and any combination of the foregoing. These inputs may be received from any of plurality of types of user input devices, for example, keyboard 110, mouse 112, a touch screen, a trackball, a microphone, or any other type of input device.

The issue tracking engine 102 may be configured to create one or more issue resolutions, to associate/disassociate software component versions with issue resolutions based on the user inputs 114, and to store information relating thereto in one or more of the data structures 108 of database 106, for example, as described in more detail below. As used herein, associating a software component version with an issue resolution is the same as adding a software component version to an issue resolution. Similarly, disassociating a software component version from an issue resolution is the same as removing a software component version from an issue resolution.

Each modification (e.g., addition, change, deletion) to an issue resolution may be stored along with a transaction number so that a history of changes to issue resolutions may be maintained.

Engine 102 may be configured to access one or more of the data structures 108, based on user inputs 114, to determine the software component versions included in an issue resolution at a particular time. Further, for each determined component version, engine 102 may be configured to determine whether the software component version is/was included in a stream at a particular time. From these determinations, issue tracking engine 102 may determine which component versions included in an issue resolution at a particular time are included in a stream at a particular time. For the remainder of the detailed description, determining whether a software component version "was" included in a stream at a particular time (e.g., a queried time) covers a scenario in which the particular time is the current time. Thus, even if the particular time is the current time, an act of determining may still be referred to in the past tense, e.g., determining whether the software component version "was" included in a stream at a particular time.

The remainder of the detailed description proceeds as follows: First, file hierarchies, stream hierarchies and software component versions (FIGS. 2-5) are discussed to provide context for the remaining description. This discussion is followed by an example of a method of modifying an issue resolution (e.g., associating and disassociating software component versions). (FIGS. 6 and 7). Next, various data structures that may be used in embodiments of the invention are described (FIGS. 8-12), followed by an example of a method of determining the software component versions of an issue resolution included in a stream at a particular time (FIGS. 13-19). The description concludes with a more detailed example of a system for modifying an issue resolution and for determining which software component versions of an issue resolution are included in a stream at a particular time (FIGS. 20-22).

FIG. 2 is a diagram illustrating an example of a file hierarchy 200. Directory 200 includes root directory 201. Root directory 201 includes directories 202, 208 and 210 and files 204, 206 and 212. Directory 202 includes directories 216 and 218, and file 214. Directory 218 includes directories 220 and 124, and directory 220 includes file 222. Directory 224 includes directory 232 and files 226, 228, 230 and 234.

File hierarchy 200, in particular File 206, is referred to throughout the remainder of the detailed description, as is the stream hierarchy 301 illustrated in FIG. 3, which will now be described.

FIG. 3 is an example of a screen shot illustrating an example of a GUI display 300 that includes a stream hierarchy 301. Stream hierarchy 301 includes streams 302, 304, 306, 308 and 310. Stream 302 is the source stream (defined above) of hierarchy 301, from which the remaining streams are derived, and streams 308 and 310 are workspaces (defined above). In some embodiments, any changes to a development project (e.g., adding, modifying and defuncting (e.g., deleting) files or directories) are initiated within a workspace.

It should be appreciated that a user may make changes to software components outside of the scope of the project itself. For example, some CM applications, such as those available from AccuRev, Inc., enable a user to create, change and delete software components (which may have originated within the project) on the user's computer, for example, using any of a variety of editors or software tools. However, the user has the option of specifying whether these changes are recorded as part of the project. If not recorded, the changes do not affect the software project. The systems and methods described herein are concerned with changes to a software project, not changes made by a user that are not recorded as part of the project. Accordingly, for the remainder of the detailed description, when software components are described as being modified, changed, added or removed from a workspace, it is meant that these transactions have been recorded as part of the workspace, unless otherwise specified.

If changes made within a workspace are to be made part of other versions (e.g., streams) of the project, the elements affected by the changes may be propagated up through the hierarchy to the source stream (e.g., source stream 302). As used herein, to "promote" means to propagate up a hierarchy, whereas "update" means to propagate down through a hierarchy. For example, a file added to workspace 310 then may be promoted to workspace 306, from which the file then may be promoted to source stream 302. Stream 304 then may be updated with the added file.

GUI display 300 may include visual indicators to assist a user in determining whether a stream is a workspace. For example, GUI display 300 provides workspace indicators 318 and 320 to indicate that streams 308 and 310, respectively, are workspaces. Other indicators may be used.

GUI display 300 also may include visual indicators to indicate whe