Software version control methods, control devices, and storage media

Abstract

A software portfolio version control method, control device, and storage medium are disclosed. The software portfolio includes multiple configurations and multiple project files, with each configuration including at least one of the multiple project files. The software portfolio version control method includes: obtaining update information of a first project file from the multiple project files; determining a first configuration that contains the first project file from the multiple configurations, and updating the version information of the first configuration; and updating the version information of the software portfolio based on the updated version information of the first configuration. By updating the version information of the corresponding configuration according to the update information of the project files, and thus updating the version information of the software portfolio, the version information of the software portfolio can be used to quickly locate the modification of the project file causing the problem during regression testing.

Description

Technical Field

[0001] Embodiments of this disclosure relate to a software portfolio version control method, control device, and non-transitory storage medium. Background Technology

[0002] A software stack comprises multiple software components, often referred to as a software ensemble. Within a software ensemble, the development of each component can be independent, but they also require collaboration to deliver the best user experience. For example, the GPGPU (General-Purpose Graphics Processing Unit) ecosystem is a type of software stack, encompassing hardware drivers, development and debugging tools, performance analysis tools, and AI frameworks. When issues arise during the development of a software ensemble, global version control can be implemented to quickly pinpoint the problematic file's code. Version control refers to the management of changes to various program code, configuration files, and documentation documents during software development; its primary function is tracking file changes. Summary of the Invention

[0003] This disclosure provides at least one embodiment of a software portfolio version control method, wherein the software portfolio includes multiple configurations and multiple project files, each configuration includes at least one of the multiple project files, the method includes: obtaining update information of a first project file in the multiple project files; determining a first configuration in the multiple configurations that includes the first project file, and updating the version information of the first configuration; and updating the version information of the software portfolio based on the updated version information of the first configuration.

[0004] At least one embodiment of this disclosure also provides a software portfolio version control device, wherein the software portfolio includes multiple configurations and multiple project files, each configuration including at least one of the multiple project files, the device comprising: an update information acquisition module configured to acquire update information of a first project file among the multiple project files; a configuration version information update module configured to determine that the multiple configurations include a first configuration containing the first project file, and update the version information of the first configuration; and a software portfolio version information update module configured to update the version information of the software portfolio based on the updated version information of the first configuration.

[0005] At least one embodiment of this disclosure also provides a software portfolio version control apparatus, comprising: a memory for non-temporarily storing computer-executable instructions; and a processor for running the computer-executable instructions, wherein the computer-executable instructions, when run by the processor, execute the software portfolio version control method provided in any embodiment of this disclosure.

[0006] At least one embodiment of this disclosure also provides a non-transitory storage medium for non-transitory storage of computer-executable instructions, wherein when the computer-executable instructions are executed by a computer, the software combination version control method provided in any embodiment of this disclosure is executed. Attached Figure Description

[0007] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. Obviously, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure.

[0008] Figure 1 A schematic diagram of a software portfolio version control flowchart provided in one embodiment of this disclosure;

[0009] Figure 2 A flowchart illustrating a software composite version control method applied to a distributed version control system, as provided in an embodiment of this disclosure;

[0010] Figure 3 An example diagram illustrating the representation of engineering information provided in one embodiment of this disclosure;

[0011] Figure 4 This is an embodiment of the present disclosure providing a representation of software portfolio version information;

[0012] Figure 5 A comparative diagram showing how missing entries are added to the project information table and the software combination version information table after a first project file provided in an embodiment of this disclosure is lost due to differences;

[0013] Figure 6 This is an embodiment of the present disclosure providing a representation of software portfolio version difference information;

[0014] Figure 7 A schematic block diagram of a software composite version control device provided in an embodiment of this disclosure;

[0015] Figure 8 A schematic block diagram of another software combined version control device provided for some embodiments of this disclosure;

[0016] Figure 9 This is a schematic diagram of a non-transitory storage medium provided for some embodiments of this disclosure. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0018] Unless otherwise defined, the technical or scientific terms used in this disclosure shall have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms “first,” “second,” and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an,” “a,” or “the,” and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms “including,” “comprising,” or “containing,” and similar terms mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. The terms “connected,” “linked,” or similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms “upper,” “lower,” “left,” and “right,” etc., are used only to indicate relative positional relationships, and these relative positional relationships may change accordingly when the absolute position of the described objects changes.

[0019] The present disclosure will now be described through several specific embodiments. To keep the following description of the embodiments of the present disclosure clear and concise, detailed descriptions of known functions and components are omitted. When any component of an embodiment of the present disclosure appears in more than one drawing, the component is indicated by the same or similar reference numerals in each drawing.

[0020] In a software suite, each file can be assigned a version number for each change. This version number allows developers to easily view historical changes and facilitates troubleshooting.

[0021] Currently, there are various tools available in the industry for providing global version control for software assemblies. For example, one tool is a distributed version control system; however, these tools lack correlation information between the project files they manage, making it impossible to determine the order in which project files were changed. Managing all project files with a single version control program would lead to drawbacks such as wasted disk space, wasted bandwidth, reduced development efficiency, and loss of historical information. Another tool is a server / client-based control software where the server can provide a version number for each file commit, providing version information; however, this is expensive and cannot work offline. However, none of the above tools can provide version information for software assemblies that may have multiple configurations.

[0022] This disclosure provides at least some embodiments of a software portfolio version control method. The software portfolio includes multiple configurations and multiple project files, and each configuration includes at least one of the multiple project files. The software portfolio version control method includes: obtaining update information of a first project file among the multiple project files; determining a first configuration among the multiple configurations that contains the first project file, and updating the version information of the first configuration; and updating the version information of the software portfolio based on the updated version information of the first configuration.

[0023] Some embodiments of this disclosure also provide a software composite version control apparatus and a non-transitory storage medium corresponding to the software composite version control method.

[0024] The software assembly version control method provided in the embodiments of this disclosure can update the version information of the configuration corresponding to the project file according to the update information of the project file, and then update the version information of the software assembly. During regression testing, the project file causing the problem can be quickly located through the version information of the software assembly.

[0025] The following detailed description, with reference to the accompanying drawings, outlines some embodiments and examples of this disclosure. It should be understood that the specific implementations described herein are for illustrative and explanatory purposes only and are not intended to limit the scope of this disclosure.

[0026] Figure 1 A flowchart illustrating a software portfolio version control method provided for some embodiments of this disclosure.

[0027] For example, the software assembly involved includes multiple configurations and multiple project files, with each configuration including at least one of the multiple project files. For example, the software assembly includes project files 1 to N, and configurations 1 to M, where N and M are positive integers greater than 1. Each configuration may include at least one of project files 1 to N. For example, configuration 1 may include project files 1, 2, and 3; configuration 2 may include project files 3 and 4; configuration 3 may include project files 1 to Nn (n less than N), etc., and configuration M may include only project file N. For example, each project file corresponds to any development file in the software assembly, such as source code files, documentation, etc. The embodiments of this disclosure do not limit this; for example, source code files are used to implement one or more software modules.

[0028] like Figure 1 As shown, the software portfolio version control method includes the following steps S100 to S300.

[0029] Step S100: Obtain the update information of the first project file among multiple project files.

[0030] For example, multiple project files within a software portfolio can be maintained in a software version control system, which can be set up on a local area network (LAN) and / or a wide area network (WAN). Alternatively, the software version control system can be set up simultaneously on both a LAN and a WAN (e.g., the Internet). When a developer updates a currently being written project file, they can first submit it to the software version control system on the LAN, and then the LAN's software version control system synchronizes the update to the WAN's software version control system. For example, the software version control system can employ a system commonly used in the field, whereby when a developer submits an update to any project file stored therein, the software version control system generates update information about that project file based on the submitted updated file.

[0031] Here, "first project file" can refer to any of the multiple project files that has been updated, rather than a specific project file. Correspondingly, the update information of the first project file includes the update information resulting from the changes made to the first project file.

[0032] For example, during the development of a software system, developers can update the source code in a project file, creating a new project file. This new project file is then submitted to the software version control system over the network, causing the project file to be updated. This update information can be obtained, such as the commit hash, the submitter, or commit messages. The commit messages explain the functionality implemented by the newly added or modified code.

[0033] A database can be used to implement a project information table to record update information for project files. For each update, a version number is generated for that project file. This disclosure does not limit the type of database or its specific implementation.

[0034] Step S200: Determine the first configuration that contains the first project file among multiple configurations, and update the version information of the first configuration.

[0035] For example, when a first project file (i.e., any project file in the software portfolio) is updated, a first configuration containing the first project file is determined among multiple configurations of the software portfolio. Here, a configuration of the software portfolio refers to one or more functions implemented by multiple projects combined together. For example, for a software portfolio of a GPGPU (General Purpose Graphics Processing Unit) ecosystem, the multiple configurations can be hardware drivers, development and debugging tools, performance analysis tools, AI frameworks, etc. Each configuration can include one or more project files (e.g., source code files), and these configurations can share one or more common project files, or they can share private project files. These common project files can be reused in different configurations. For example, common project files can be project files involving APIs (Application Programming Interfaces), project files involving SDKs (Software Development Kits), etc., and the embodiments of this disclosure do not limit this.

[0036] It should be noted that "first configuration" refers to any configuration that includes the first project file, and this configuration can be any of multiple configurations. Then, the version information of the first configuration is updated based on the update information of the first project file; that is, since the first project file, as a component, has been updated, the first configuration, as a component, is naturally also updated. For example, a new sequence number can be added under the configuration name of the first configuration to identify the update information of the first project file, thus obtaining the updated version information of the first configuration. For example, the updated version information of the first configuration includes the first configuration name, the newly added sequence number, and the update information of the first project file.

[0037] For example, suppose configuration 1 = {project file 1, project file 2, project file 3}, configuration 2 = {project file 3}, and configuration 3 = {project file 1, project file 4, project file 10, project file 15}. When project file 1 is updated, configuration 1 and configuration 3 containing project file 1 are determined from configuration 1, configuration 2, and configuration 3, and then the version information of configuration 1 and configuration 3 is updated.

[0038] Specifically, for example, in configuration name 'Configuration 1', if project file 1 is updated, a new sequence number 'i' (where 'i' is a positive integer greater than 1) is added to identify the update information of the currently updated project file 1. Similarly, in configuration name 'Configuration 3', if project file 1 is updated, a new sequence number 'j' (where 'j' is a positive integer greater than 1) is added to identify the update information of the currently updated project file 1. The updated version information of Configuration 1 includes the configuration name 'Configuration 1', sequence number 'i', and the update information of project file 1; the updated version information of Configuration 3 includes the configuration name 'Configuration 3', sequence number 'j', and the update information of project file 1.

[0039] Step S300: Update the version information of the software combination based on the updated version information of the first configuration.

[0040] For example, a software combination version information table can be implemented using a database to record updated version information of the software combination. This disclosure does not limit the type of database or the specific implementation method.

[0041] Based on the updated version information of the first configuration, the version information of the software combination is updated. That is, for the updated version information of the first configuration, the corresponding software combination version number is continuously generated. The updated version information of the software combination includes the newly added software combination version number, the name of the first configuration, the current serial number of the first configuration, and the current version number of each project file included in the first configuration.

[0042] For example, suppose configuration 1 = {project file 1, project file 2, project file 3}, configuration 2 = {project file 3}, and configuration 3 = {project file 1, project file 2, project file 4, project file 10, project file 15}. When project file 1 is updated, configuration 1 and configuration 3 containing project file 1 are identified, and their version information is updated accordingly. The updated version information of configuration 1 includes the configuration name "configuration 1", sequence number "i", and the version number of project file 1. The updated version information of configuration 3 includes the configuration name "configuration 3", sequence number "j", and the version number of project file 1. For example, a version number "x" for the software combination is generated based on the updated version information of configuration 1. Then, a version number "x+1" for the software combination is generated based on the updated version information of configuration 3. The updated version information of the software combination includes two entries:

[0043] Article 1: x, configuration 1, serial number i, version number of project file 1;

[0044] Article 2: x+1, configuration 3, serial number j, version number of project file 1.

[0045] The next time project file 3 is updated, configurations 1 and 2, which contain project file 2, are identified, and their version information is updated accordingly. The updated version information for configuration 1 includes the configuration name "Configuration 1", sequence number i+1, and the version number of project file 3. The updated version information for configuration 2 includes the configuration name "Configuration 2", sequence number k, and the version number of project file 3. For example, a version number x+2 for the software assembly is generated based on the updated version information for configuration 1. Then, a version number x+3 for the software assembly is generated based on the updated version information for configuration 3. The updated version information for the software assembly includes two entries:

[0046] Article 3: x+2, configuration 1, serial number i+1, version number of project file 3;

[0047] Article 4: x+3, configuration 2, serial number k, version number of project file 3.

[0048] For example, to facilitate management, a corresponding configuration file can be created for each configuration. These configuration files record file information for at least one project file within the corresponding configuration. For example, file information includes: project file name, source code path, branch name, etc. Thus, the configuration file can be conveniently used to identify the first configuration among multiple configurations that includes a specific first project file. Here, the source code path records the storage path of the project file's source code. When developing software, multiple people may simultaneously develop features or fix bugs for the same software, resulting in multiple release versions that need to be maintained. Branches are used to divide and save the overall process of modification records. A branch is not affected by other branches, so multiple modifications can be made simultaneously. Branches can be merged later. The branch name identifies which branch the current first project file's modifications originated from.

[0049] For example, to determine a first configuration that contains a first project file among multiple configurations, synchronization can be used. For instance, a synchronization task can be created for each configuration (including the first configuration); executing this task allows the determination of the updated first configuration in response to information indicating an update to the first project file. For example, a continuous integration tool can be used to create and execute the synchronization task, such as using a configuration file, and executing the task periodically or intermittently, thereby achieving continuous monitoring and integration. For instance, tools commonly used in the art can be used to create and execute a synchronization task based on a configuration file.

[0050] For example, when performing a synchronization task, the current first project file included in the first configuration can be copied according to the configuration file of the first configuration, thereby constructing a version computing node.

[0051] For example, a project information table can be used to record update information for multiple project files. This project information table might include multiple project information entries, each containing a project file version number, project file identification information, source code path, branch name, and commit hash value. For instance, the project file version number could be an auto-incrementing primary key recorded in the project information table.

[0052] For example, a software portfolio version information table can be used to record and update the version information of the software portfolio. For example, the software portfolio version information table includes multiple version entries, each corresponding to a current configuration, and includes the software portfolio version number, current configuration identification information, the current sequence number of the current configuration, and the current version numbers of each project file included in the current configuration. For example, the software portfolio version number is an auto-incrementing primary key of the software portfolio version information table; another example is that the current sequence number of the current configuration is an auto-incrementing sequence number.

[0053] Figure 2 The flowchart illustrates a software portfolio version control method based on a distributed version control system, according to some embodiments of this disclosure.

[0054] In this embodiment, the software portfolio version control method utilizes version control tools to create corresponding project files for all projects in the software portfolio. For example, project files GT1 to GTN are created for projects 1 to N in the software portfolio. An existing file server can be set up or used, and the project files are sent to the file server. The file server provides space for storing each project file. A monitoring program can be used to monitor the status of the file server. When a project file on the file server is updated, the file server sends a signal to the monitoring program. Based on this signal, the monitoring program determines one or more configurations containing the updated project file from multiple configurations corresponding to project files GT1 to GTN, and sends one or more configurations containing the updated project file to the version computing node. The version computing node obtains the version information of the updated configuration, and then updates the version information of the corresponding software portfolio.

[0055] It should be noted that the software used to implement the version control method provided in this embodiment includes, but is not limited to, a distributed version control system, and can also be replaced with other types of version control systems. The embodiments disclosed herein do not limit this.

[0056] For example, after creating the corresponding project files, the software portfolio version control method also includes: creating a corresponding configuration file for each configuration, which is used to record the file information of at least one project file in the corresponding configuration.

[0057] For example, project file information includes: project file name, source code path, and branch name. The source code path can be a storage path on a file server, such as the overall path of the project file. As mentioned above, different branches can each correspond to multiple independent and non-interfering copies of the same initial file, allowing different individuals or teams to independently develop different parts of the project file. The same branch can produce different updates to the project file, and different project files may also correspond to the same branch. Different branches of the same project file may be assigned to different configurations.

[0058] For example, a file server can create a corresponding configuration file for each configuration in a software assembly. The configuration file format can be .xml (but not limited to this; other file formats such as .txt can also be used). For multiple project files, configuration files can range from 1.xml to M.xml (where M is an integer greater than 1). Each configuration file contains file information for each project file within its corresponding configuration, such as the project file name, source code path, and branch name. The configuration file prepares for subsequent determination of the first configuration containing the first project file to be discussed across multiple configurations, such as establishing a synchronization task. In other examples, a single database file can be used to manage file information for each project file in different configurations, instead of creating separate configuration files.

[0059] For example, assuming configuration 1 = {GT1, GT2, GT3}, create a configuration file 1.xml corresponding to configuration 1. Configuration file 1.xml includes file information for the GT1 project files, the GT2 project files, and the GT3 project files. For example, configuration file 1.xml includes: (GT1, source code path 1, branch a); (GT2, source code path 2, branch b); (GT3, source code path 3, branch c). Configuration file 2.xml includes: (GT1, source code path 1, branch b); (GT2, source code path 2, branch b); (GT3, source code path 3, branch c).

[0060] For example, based on the configuration file mentioned above, the configuration file can be used to determine the first configuration among multiple configurations, including the first project file as the subject of discussion.

[0061] For example, during development, developers can commit newly added or modified code to a specific branch of a project file. Since the file information of the first project file that is being updated includes the project file name, source code path, and branch name, it's possible to determine which configuration file contains the same project file name and branch name as the first project file based on the project file name and branch name (the branch from which the newly added or modified code was committed). For example, suppose configuration file 1.xml includes: (GT1, source code path 1, branch a), (GT2, source code path 2, branch b); configuration file 2.xml includes: (GT1, source code path 1, branch b), (GT2, source code path 2, branch b), (GT3, source code path 3, branch a); and configuration file 3.xml includes: (GT1, source code path 1, branch a)(GT6, source code path 6, branch a). If the currently added or modified code is committed to branch a of GT1, then configuration files 1.xml and 3.xml (i.e., configuration files 1 and 3 containing GT1) are determined to have been updated.

[0062] For example, a monitoring program can be used to create synchronization tasks for each configuration in the software assembly. These synchronization tasks monitor the status of project files on the file server, and once new or modified code is committed to a branch of a project file, the corresponding configuration file is copied to the version compute node.

[0063] In a preferred scenario, to avoid duplicate copying during multiple copying processes, all configuration files corresponding to the configuration can be copied to the version compute nodes during the first synchronization, i.e., synchronization task 1 to synchronization task M, and the next synchronization will be incremental.

[0064] For example, to determine a first configuration that includes a first project file as the subject of discussion among multiple configurations, a synchronization task is established for the first configuration; the synchronization task is executed, and the first configuration is determined in response to the first project file being updated.

[0065] When performing a synchronization task, the current first project file included in the first configuration is copied to the version computing node according to the configuration file of the first configuration.

[0066] For example, in response to an update to the first project file in the file server, the file server sends a signal to the monitoring program. Based on this signal, the monitoring program uses the configuration files for each configuration in the software suite to determine the first configuration, which includes the first project file. It then executes the established synchronization task for the first configuration, that is, according to the configuration file of the first configuration, it copies the current first project file included in the first configuration to the version compute node. Of course, it is also possible to copy the file information of all project files included in the first configuration to the version compute node; this is not limited to this approach.

[0067] For example, assuming configuration 1 = {GT1, GT2, GT3}, configuration 2 = {GT3}, and configuration 3 = {GT1, GT4, GT10, GT15}, in response to an update of GT1 in the file server, the file server sends a signal to the monitoring program. The monitoring program uses configuration1.xml, configuration2.xml, and configuration3.xml to determine which configurations 1 and 3 contain GT1. The established synchronization tasks for configurations 1 and 3 are then executed, including synchronization task 1 and synchronization task 3. Specifically, based on configuration files 1.xml and 3.xml, the file information of GT1 in configuration 1 and configuration file 3.xml is copied to the version computing node.

[0068] For example, multiple project files are stored in a file version control system, and correspondingly, update information for the first project file is retrieved from the file version control system.

[0069] For example, a file version control system can be a general-purpose system applied to a file server. After receiving the file information of the current first project file included in the first configuration, the version compute node retrieves the update information of the first project file from the file version control system. For example, after receiving the file information of GT1 in configuration 1 and the file information of GT1 in copy configuration 1, the version compute node retrieves the update information of the first project file from the file version control system.

[0070] For example, a project information table can be used to record update information for multiple project files. The project information table may include multiple project information entries, each containing the project file version number, project file identification information, source code path, branch name, and commit hash.

[0071] For example, the project file version number is an auto-incrementing primary key of the project information table record.

[0072] For example, Figure 3An exemplary diagram illustrating project information is provided. For instance, when creating a project information table in a database (the embodiments of this disclosure are not limited to any particular database type), a primary key is used. Each primary key entry must be unique, so an "id" field is often used as the primary key, assigned an "auto_increment" attribute, allowing the "id" field to increment by "1" for each record. The table's "id" represents the project file version number, indicating a specific modification to a project file. A corresponding auto-incrementing primary key is generated, and the version numbers for different project files are consecutive. For example... Figure 3 As shown, the project file version numbers increment sequentially from i to i+N. Project file version number i corresponds to project 1, project file version number i+1 also corresponds to project 1, project file version number i+2 corresponds to project 2, and so on. Each entry in this table includes a file information section and an update information section corresponding to the project file version number. The file information section may include project file identification information (e.g., project file name), source code path, and branch name; the update information section includes the commit hash, committer, and commit message.

[0073] It is important to note that before using the project information table to record update information for multiple project files, you should first check if there are duplicate records in the history. If not, add a new record; otherwise, ignore the update information.

[0074] For example, a software portfolio version information table is used to record and update the version information of software portfolios. The software portfolio version information table includes multiple software portfolio version entries, each corresponding to a current configuration, and includes the software portfolio version number, current configuration identification information, the current sequence number of the current configuration, and the current version numbers of each project file included in the current configuration. For example, the software portfolio version number is an auto-incrementing primary key of the software portfolio version information table, and the software portfolio version numbers resulting from different configurations are consecutive; the sequence number of each configuration is an auto-incrementing sequence number, meaning that different versions of each configuration have consecutive sequence numbers.

[0075] For example, Figure 4 This illustrates an exemplary representation of software portfolio version information. For example, the `id` in the table represents the software portfolio version number, used to indicate a specific modification to a project file within a given configuration, and is assigned an auto-incrementing primary key. Each software portfolio version entry in the table contains the software portfolio version number, along with the current configuration identification information (e.g., configuration name), the current sequence number of the current configuration, and the current version numbers of each project file included in the current configuration. Sequence numbers corresponding to the same configuration name are consecutive, while sequence numbers corresponding to different configurations are sorted separately. For example... Figure 4 As shown, the software package version number increases sequentially from x to y. Software package version number x corresponds to configuration 1, software package version number x+2 also corresponds to configuration 1, software package version number x+1 also corresponds to configuration 3, and so on. Configuration 1 corresponding to software package version number x has the sequence number "1", and correspondingly, configuration 1 corresponding to software package version number x+2 has the sequence number "2". Other configurations, such as configuration 2, configuration 3, etc., are also numbered starting from the sequence number "1".

[0076] The version number of the project file is used to index the file information and update information in the project information table. When a software assembly experiences a regression issue, testers can quickly locate the updated version of the project file causing the problem simply by searching for the software assembly version number or by indexing the update information of the project file in the project information table based on the software assembly version number.

[0077] For example, assuming configuration 1 = {GT1, GT2, GT3}, configuration 2 = {GT3}, and configuration 3 = {GT1, GT4, GT10, GT15}, and in response to GT1 being updated, it is determined that configurations containing GT1 are configuration 1 and configuration 3. Then, the entries recorded in the software version information table are:

[0078] Software version number x, configuration 1, configuration sequence number 1, GT1 project file version number;

[0079] The software combination version number is x+1, configuration number is 3, configuration number is 1, and the project file version number is GT1.

[0080] Following the update of GT3, it is determined that the configurations containing GT3 are configuration 1 and configuration 2. Therefore, the entries recorded in the software version information table are:

[0081] Software combination version number x+2, configuration 1, configuration sequence number 2, GT3 project file version number;

[0082] Software version number x+3, configuration 2, configuration sequence number 1, GT3 project file version number.

[0083] Specifically, software combination version number x corresponds to configuration 1, and configuration 1 corresponds to version i of project 1 (see...). Figure 3 The software portfolio version number x+1 corresponds to configuration 3, and configuration 3 also corresponds to version i of project 1. That is, both configuration 1 and configuration 3 include project 1. The same modification to project 1 (i.e., version i) simultaneously causes configuration 1 and configuration 3 to be updated, resulting in two software portfolio version numbers x and x+1.

[0084] Similarly, it can be noted that software package version number x+2 corresponds to configuration 1, and configuration 1 corresponds to version i+3 of project 3 (see...). Figure 3 The software combination version number x+3 corresponds to configuration 2, and configuration 2 also corresponds to version i+3 of project 3. That is, both configuration 1 and configuration 2 include project 3. The same modification to project 3 (i.e., version i+3) simultaneously causes configuration 1 and configuration 2 to be updated, resulting in two software combination version numbers, x+2 and x+3.

[0085] Furthermore, since the monitoring program relies on the submission operation and parameters of the updated project files to trigger the execution of synchronization tasks, there may be a delay between two adjacent synchronization tasks. This results in the latter synchronization task being executed twice consecutively, while the former synchronization task is not executed. Consequently, the project information table records the last update of the current project file. This may lead to the loss of differences between adjacent sequence numbers of the same configuration (e.g., the same configuration, which can be any of multiple configurations) recorded in the software combination version information table and the same project file (which can be any of multiple project files) corresponding to adjacent sequence numbers.

[0086] Since there is a risk of losing the differences between adjacent serial numbers with the same configuration in the software combination, all differences need to be recorded in order to make the results of future regression tests more intuitive.

[0087] Figure 5 An exemplary diagram illustrates the comparison of supplementing the missing entries in the project information table and the software package version information table after a single project file has been lost due to differences.

[0088] from Figure 5 As can be seen from the table, the project file (taking project file 1 as an example) was updated four times consecutively. However, the second and third updates between the first and fourth updates were not synchronized due to the aforementioned reasons. The project information table only records the update information for the first update (e.g., the corresponding project file version number is i, and the commit hash value is hash_i) and the update information for the fourth update (e.g., the corresponding project file version number is i+1, and the commit hash value is hash_j). Since a loss of update differences was detected for project file 1, the project information table will be updated with the record for the second update (project file version number is k, and the commit hash value is hash_k) and the third update (project file version number is k+1, and the commit hash value is hash_m), in addition to the existing entries.

[0089] Correspondingly, in the software combination version information table, if two different version numbers (e.g., c and c+1) correspond to the same configuration (e.g., configuration 1, including project file 1) and this configuration has adjacent sequence numbers (e.g., j and j+1, corresponding to project file 1 with project version numbers i and i+1), then the entry for software combination version number c+1 is added. It should be noted that these two different software combination version numbers do not necessarily have to be adjacent version numbers; as long as they correspond to the same configuration (the same configuration name) and the same configuration has adjacent sequence numbers, it is acceptable. The software combination version number c+1 is associated with project file version numbers k and k+1 in project file 1. Without changing the existing software combination version number c+1, update information for the configuration corresponding to software combination version number c+1 is added. That is, it not only corresponds to project file version number i, but also further corresponds to project file version numbers k and k+1. The updates corresponding to project file version numbers k and k+1 are included in project file version number i+1.

[0090] For example, Figure 6 The diagram illustrates how the updated entry for software combination version number c+1 can be extracted to establish a software combination version difference information table. The first column represents the software combination version number c+1, the second column represents the project file version number i+1 obtained after the last update of the second project file corresponding to software combination version number c+1, and the updated project file version numbers (project file version number k and project file version number k+1) of the missing second project file. The software combination version difference information table can be implemented using a database; this disclosure embodiment does not limit the type of database or the specific implementation method.

[0091] As can be seen from the above description, the software portfolio version control method of this disclosure embodiment may further include: determining that two different version numbers of the same second configuration of the software portfolio have adjacent serial numbers, and that the same second project file corresponding to the adjacent serial numbers has lost differences. Here, the second configuration (configuration 1 is used as an example in the above example) and the second project file corresponding to the second configuration (project file 1 is used as an example in the above example) are any configuration and project file discussing the loss of differences, and the embodiments of this disclosure do not limit this.

[0092] For example, the software portfolio version control method of this disclosure may further include: using a software portfolio version difference information table to record lost differences, wherein the entries of the software portfolio version difference information table include the software portfolio version number and the updated project file version number of the lost second project file.

[0093] For example, the software portfolio version difference information table is used to record the current software portfolio version number and the updated project file version number of the missing second project file, where the second project file is any one of the multiple project files with a missing difference.

[0094] For example, the software portfolio version control method of this disclosure may further include: determining that the same second configuration with two different version numbers in the software portfolio version information table has adjacent serial numbers; determining that the same second project file corresponding to adjacent serial numbers in the project information table has different commit hash values; and in the file version control system, querying whether there is a difference loss between the same second project file having different commit hash values.

[0095] The software assembly version control method provided in at least one embodiment of this disclosure can update the version information of the corresponding configuration based on the update information of the project files, thereby updating the version information of the software assembly. This achieves version tracking of the entire software assembly, while each project file in the software assembly can operate independently without interfering with others. In automated regression testing programs, the modifications to the project files causing the problem can be quickly located by querying the project information table, the software assembly version information table, and the software assembly version difference information table.

[0096] In addition, in at least one example, the updated version information (project information table, software combination version information table, software combination version difference information table) is stored in a database and can be visualized through a web interface.

[0097] At least some embodiments of this disclosure also provide a software composite version control device. Figure 7 This is a schematic block diagram of a software portfolio version control device provided for some embodiments of this disclosure.

[0098] For example, such as Figure 7 As shown, the software suite version control device 100 includes: an update information acquisition module 110, a configured version information update module 120, and a software suite version information update module 130.

[0099] For example, the update information acquisition module 110 is configured to acquire update information of the first project file in multiple project files; the configuration version information update module 120 is configured to determine the first configuration that contains the first project file in multiple configurations and update the version information of the first configuration; the software combination version information update module 130 is configured to update the version information of the software combination based on the updated version information of the first configuration.

[0100] For example, to determine a first configuration that contains a first project file among multiple configurations, and to update the version information of the first configuration, the version information update module 120 can be configured to perform the following operations: establish a corresponding configuration file for each configuration, the configuration file being used to record the file information of at least one project file in the corresponding configuration.

[0101] For example, file information includes project file name, source code path, and branch name.

[0102] For example, to determine a first configuration that includes a first project file among multiple configurations, and to update the version information of the first configuration, the version information update module 120 can also be configured to perform the following operation: use a configuration file to determine the first configuration that includes the first project file among multiple configurations.

[0103] For example, to determine a first configuration that contains a first project file among multiple configurations, and to update the version information of the first configuration, the version information update module 120 can also be configured to perform the following operations: establish a synchronization task for the first configuration, execute the synchronization task, and determine the first configuration in response to the first project file being updated.

[0104] For example, to perform the synchronization task, the version information update module 120 can also be configured to perform the following operation: copy the current first project file included in the first configuration according to the configuration file of the first configuration.

[0105] For example, multiple project files are stored in a file version control system. In order to obtain the update information of the first project file among the multiple project files, the update information acquisition module 110 can be configured to perform the following operation: obtain the update information of the first project file from the file version control system.

[0106] For example, to obtain the update information of the first project file among multiple project files, the update information acquisition module 110 can also be configured to perform the following operations: use a project information table to record the update information of multiple project files. The project information table includes multiple project information entries, and each project information entry includes the project file version number, project file identification information, source code path, branch name, and commit hash value.

[0107] For example, the project file version number is an auto-incrementing primary key of the project information table record.

[0108] For example, to update the version information of the software combination based on the updated version information of the first configuration, the software combination version information update module 130 can be configured to perform the following operations: record and update the version information of the software combination using the software combination version information table, wherein the software combination version information table includes multiple version entries, each version entry corresponds to a current configuration, and includes the software combination version number, current configuration identification information, current sequence number of the current configuration, and current version number of each project file included in the current configuration.

[0109] For example, the software portfolio version number is the auto-incrementing primary key of the software portfolio version information table; the current sequence number of the current configuration is the auto-incrementing sequence number.

[0110] For example, the software portfolio version control device 100 may also include a difference loss determination module 140, which is configured to determine that two different version numbers of the same second configuration of the software portfolio have adjacent serial numbers, and the same second project file corresponding to the adjacent serial numbers has a difference loss.

[0111] For example, the software portfolio version control device 100 may also include a difference information table recording module 150, which is configured to record lost differences using a software portfolio version difference information table. The entries in the software portfolio version difference information table include the software portfolio version number and the updated project file version number of the lost second project file.

[0112] For example, to determine that two different versions of the same second configuration of a software combination have adjacent serial numbers and that the corresponding second project files have lost differences, the difference loss determination module 140 can be configured to perform the following operations: determine that two different versions of the same second configuration in the software combination version information table have adjacent serial numbers; determine that the corresponding second project files in the project information table have different commit hash values; and in the file version control system, query whether there is a difference loss between the two second project files with different commit hash values.

[0113] Figure 8 A schematic block diagram of another software combined version control device provided for some embodiments of this disclosure.

[0114] For example, such as Figure 8 As shown, the software portfolio version control apparatus 500 includes a memory 510 and a processor 520. For example, the memory 510 is used to non-temporarily store computer-executable instructions, and the processor 520 is used to run the computer-executable instructions, which, when run by the processor 520, execute the software portfolio version control method provided in any embodiment of this disclosure.

[0115] For example, memory 510 and processor 520 can communicate with each other directly or indirectly. For example, in some examples, such as Figure 8 As shown, the software version control device 500 may further include a system bus 530, through which the memory 510 and processor 520 can communicate with each other. For example, the processor 520 can access the memory 510 via the system bus 1006. In other examples, components such as the memory 510 and processor 520 may communicate via a network connection. The network may include a wireless network, a wired network, and / or any combination of wireless and wired networks. The network may include a local area network, the Internet, a telecommunications network, an Internet of Things (IoT) based on the Internet and / or telecommunications networks, and / or any combination of the above networks. Wired networks may use methods such as twisted-pair cables, coaxial cables, or fiber optic transmission for communication, while wireless networks may use methods such as 3G / 4G / 5G mobile communication networks, Bluetooth, Zigbee, or WiFi. This disclosure does not limit the type and function of the network.

[0116] For example, processor 520 can control other components in the software combination version control device to perform desired functions. Processor 520 can be a device with data processing and / or program execution capabilities, such as a central processing unit (CPU), tensor processor (TPU), network processor (NP), or graphics processing unit (GPU); it can also be a digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The central processing unit (CPU) can be based on x86 or ARM architectures, etc. The GPU can be integrated directly onto the motherboard or built into the motherboard's northbridge chip. The GPU can also be built into the central processing unit (CPU).

[0117] For example, memory 510 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc.

[0118] For example, one or more computer instructions may be stored on memory 510, and processor 520 may execute the computer instructions to perform various functions. Various application programs and various data may also be stored in the computer-readable storage medium, such as software package version control code, a first integrated netlist, a first layout netlist, physical constraints, a second integrated netlist, a second layout netlist, and various data used and / or generated by the application programs.

[0119] For example, some computer instructions stored in memory 510 can perform one or more steps in the software portfolio version control method described above when executed by processor 520.

[0120] For example, such as Figure 8 As shown, the software composite version control device 500 may also include an input interface 540 that allows external devices to communicate with the synonym mining device 500. For example, the input interface 540 may be used to receive instructions from external computer devices, users, etc. The software composite version control mining device 500 may also include an output interface 550 that enables the software composite version control device 500 to interconnect with one or more external devices. For example, the software composite version control device 500 may display images, etc., through the output interface 550. External devices that communicate with the software composite version control device 500 through the input interface 1010 and / or the output interface 1012 may be included in an environment that provides any type of user interface that a user can interact with. Examples of user interface types include graphical user interfaces, natural user interfaces, etc. For example, a graphical user interface may accept input from a user using input devices such as a keyboard, mouse, remote control, etc., and provide output on an output device such as a display. Furthermore, a natural user interface allows a user to interact with the software composite version control device 500 in a manner that is not constrained by input devices such as a keyboard, mouse, remote control, etc. In contrast, natural user interfaces can rely on voice recognition, touch and stylus recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence, among others.

[0121] Furthermore, although software composite version control device 100 and software composite version control device 500 in Figure 7 and Figure 8 While both are shown as a single system, it is understood that software portfolio version control device 100 and software portfolio version control device 500 can also be distributed systems and can be deployed as cloud facilities (including public or private clouds). Thus, for example, several devices can communicate via network connections and jointly perform tasks described as being performed by software portfolio version control device 100 or software portfolio version control device 500.

[0122] For example, a detailed description of the processing procedure of the software composite version control method can be found in the relevant descriptions in the embodiments of the software composite version control method described above, and repeated details will not be repeated.

[0123] It should be noted that the software portfolio version control device provided in the embodiments of this disclosure is exemplary and not restrictive. Depending on the actual application needs, the software portfolio version control device may also include other conventional components or structures. For example, in order to realize the necessary functions of the software portfolio version control device, those skilled in the art can set other conventional components or structures according to specific application scenarios. The embodiments of this disclosure do not limit this.

[0124] The technical effects of the software composite version control device provided in the embodiments of this disclosure can be referred to the corresponding description of the software composite version control method in the above embodiments, and will not be repeated here.

[0125] At least some embodiments of this disclosure also provide a non-transitory storage medium. Figure 9 This is a schematic diagram of a non-transitory storage medium provided for some embodiments of this disclosure.

[0126] For example, such as Figure 9 As shown, the storage medium 600 non-transitory stores computer-executable instructions 601, which can execute the software combination version control method provided in any embodiment of this disclosure when executed by a computer (including a processor).

[0127] For example, one or more computer instructions may be stored on storage medium 600. Some of the computer instructions stored on storage medium 600 may be, for example, instructions for implementing one or more steps in the software composition version control method described above.

[0128] For example, the storage medium may include the storage component of a tablet computer, the hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical disc read-only memory (CD-ROM), flash memory, or any combination of the above storage media, or other suitable storage media. For example, storage medium 600 may include memory 510 in the aforementioned software combination version control device 500.

[0129] The technical effects of the storage medium provided in the embodiments of this disclosure can be found in the corresponding descriptions of the software composite version control method in the above embodiments, and will not be repeated here.

[0130] The following points need to be clarified regarding this disclosure:

[0131] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0132] (2) Where there is no conflict, features of the same embodiment and different embodiments of this disclosure can be combined with each other.

[0133] The above are merely specific embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A software portfolio version control method, wherein, The software suite includes multiple configurations and multiple project files, each configuration including at least one of the multiple project files, wherein each file in the software suite provides version information for each change, and the configuration of the software suite refers to one or more functions implemented by the included project files; The method includes: Obtain the update information of the first project file from the multiple project files; Determine that the first configuration contains the first project file among the multiple configurations, and update the version information of the first configuration; Based on the updated version information of the first configuration, update the version information of the software combination.

2. The control method according to claim 1 further includes: A corresponding configuration file is created for each configuration, wherein the configuration file is used to record file information of at least one project file in the corresponding configuration.

3. The control method according to claim 2, wherein, The file information includes: project file name, source code path, and branch name.

4. The control method according to claim 2, wherein, The step of determining that the first configuration among the plurality of configurations includes the first configuration of the first project file includes: The configuration file is used to determine the first configuration among the plurality of configurations, which includes the first project file.

5. The control method according to claim 4, wherein, The step of determining that the first configuration among the plurality of configurations includes the first configuration of the first project file further includes: Establish a synchronization task for the first configuration. The synchronization task is executed, and in response to the first project file being updated, the first configuration is determined.

6. The control method according to claim 5, wherein, The execution of the synchronization task includes: Based on the configuration file of the first configuration, copy the current first project file included in the first configuration.

7. The control method according to claim 1, wherein, The multiple project files are stored in a file version control system. The step of obtaining the update information of the first project file among the multiple project files includes: Obtain update information for the first project file from the file version control system.

8. The control method according to claim 7, wherein, The step of obtaining the updated information of the first project file in the plurality of project files also includes: The project information table is used to record the update information of the multiple project files. The project information table includes multiple project information entries. Each project information entry includes the project file version number, project file identification information, source code path, branch name, and commit hash value.

9. The control method according to claim 8, wherein, The version number of the project file is an auto-incrementing primary key recorded in the project information table.

10. The control method according to claim 8, wherein, The step of updating the version information of the software combination based on the updated version information of the first configuration includes: The version information of the software combination is recorded and updated using a software combination version information table. The software combination version information table includes multiple version entries, each version entry corresponds to a current configuration, and includes the software combination version number, current configuration identification information, current sequence number of the current configuration, and current version number of each project file included in the current configuration.

11. The control method according to claim 10, wherein, The software package version number is an auto-incrementing primary key of the software package version information table; The current sequence number of the current configuration is an auto-incrementing sequence number.

12. The control method according to claim 10, further comprising: It is determined that the same second configuration with two different version numbers of the software combination has adjacent serial numbers, and the same second project file corresponding to the adjacent serial numbers has differences and is missing.

13. The control method according to claim 12, further comprising: The missing differences are recorded using a software package version difference information table, the entries of which include the software package version number and the updated project file version number of the missing second project file.

14. The control method according to claim 13, wherein, The determination that two different versions of the software combination have adjacent serial numbers for the same second configuration and that the corresponding second project files for the adjacent serial numbers have lost differences includes: It is determined that the same second configuration with two different version numbers in the software combination version information table has adjacent serial numbers; It is determined that the same second project file corresponding to adjacent serial numbers in the project information table has different submission hash values; In the file version control system, a query is performed to find discrepancies between different commit hash values ​​for the same second project file.

15. A software composite version control device, wherein, The software suite includes multiple configurations and multiple project files, each configuration including at least one of the multiple project files, wherein each file in the software suite provides version information for each change, and the configuration of the software suite refers to one or more functions implemented by the included project files; The device includes: The update information acquisition module is configured to acquire update information of the first project file among the plurality of project files; The configured version information update module is configured to determine that the first configuration contains the first project file among the plurality of configurations, and update the version information of the first configuration; The software portfolio version information update module is configured to update the version information of the software portfolio based on the updated version information of the first configuration.

16. A software portfolio version control device, comprising: Memory is used to store non-temporary executable instructions for a computer. as well as A processor for running the computer-executable instructions, wherein the computer-executable instructions are executed by the processor during runtime according to the software portfolio version control method of any one of claims 1-14.

17. A non-transitory storage medium for non-transitory storage of computer-executable instructions, wherein, When the computer-executable instructions are executed by a computer, the software portfolio version control method according to any one of claims 1-14 is performed.

Images