Software asset management method, electronic equipment and computer readable medium

Abstract

The invention provides a software asset management method, electronic equipment and a computer readable medium, and relates to the technical field of computers. The method comprises the following steps: in response to a version submission request for a reference version and a target version, determining an operation version matched with a request type corresponding to the version submission request, obtaining an asset data file corresponding to the operation version, and comparing and analyzing each asset in the asset data file to determine a comparison result corresponding to the reference version and the target version. Outputting a version iteration page corresponding to a current version matched with the request type, displaying an asset tree list comprising at least one hierarchical node and a state identifier in the version iteration page, and outputting a reference version information area and a current version information area in response to a viewing operation for any hierarchical node in the at least one hierarchical node, the display forms of the contents in the reference version information area and the current version information area are matched with the development display form corresponding to any hierarchy node.

Description

Technical Field

[0001] This application relates primarily to the field of computer technology, and in particular to a software asset management method, electronic device, and computer-readable medium. Background Technology

[0002] In software development, asset management is a crucial technical means for development teams to conduct parallel development, code collaboration, and version control. Asset management involves comparing and merging differences between various software versions. With the expansion of software project scale, the increasing complexity of multi-person collaboration, and the widespread adoption of microservice architecture, low-code development, and cross-team collaboration, existing DiffMerge solutions have exposed many technical bottlenecks in handling asset management, urgently requiring optimization and improvement.

[0003] Currently, the commonly used DiffMerge solutions in the industry are mainly based on plain text or code-level differences comparison and merging, lacking the ability to visualize Diff and Merge for low-code assets (such as page views, process logic, data models, etc.). Summary of the Invention

[0004] Providing a mechanism to alleviate, reduce or eliminate at least one of the above problems would be beneficial.

[0005] Firstly, this application provides a software asset management method, including:

[0006] In response to version submission requests for a reference version and a target version, determine an operation version that matches the request type corresponding to the version submission request; the operation version includes an iterative version associated with the reference version and the target version, or the operation version includes the iterative version, the target version, and a baseline version common to the reference version and the target version; the request type includes comparison, first type merge, and second type merge.

[0007] Obtain the asset data file corresponding to the operation version, and perform comparative analysis on each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version;

[0008] Output the version iteration page corresponding to the current version that matches the request type. The version iteration page displays an asset tree list including at least one level node and a status identifier. The type and display position of the status identifier are determined according to the comparison result. One level node in the at least one level node corresponds to one or more assets.

[0009] In response to a viewing operation on any of the at least one level nodes, a corresponding reference version information area and a current version information area are output. The display format of the content in the reference version information area and the current version information area matches the development display format corresponding to the any level node. The display format includes plain text, list format, or key-value pair format.

[0010] Optionally, before performing comparative analysis on each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version, the method further includes:

[0011] Semantic analysis is performed on each asset in the asset data file, and data of a preset type is deleted based on the semantic analysis results.

[0012] Optionally, the reference version information area further includes a version switching view entry, which is used to switch between viewing content associated with any of the hierarchical nodes in the reference version, the target version, and the baseline version.

[0013] Optionally, after the response submits a version request for both the reference version and the target version, the method further includes:

[0014] Detect the iterative relationship between the reference version and the target version;

[0015] When the iteration relationship is across projects, the reference version is copied to obtain a mirror version of the reference version, the asset identifier of the mirror version is unified with the target version, and the mirror version with unified asset identifier is determined as the iteration version;

[0016] When the iteration relationship is the same project, the reference version is determined as the iteration version.

[0017] Optionally, after the response submits a version request for both the reference version and the target version, the method further includes:

[0018] From the pre-stored asset lineage, determine the nearest common ancestor version between the reference version and the target version, as well as the first and second timestamps of the reference version and the target version that are related to the common ancestor version, respectively;

[0019] Locate the ancestor snapshot of the common ancestor version at the target timestamp from the distributed version control system. The target timestamp is the earlier of the first timestamp and the second timestamp.

[0020] The baseline version is determined based on the ancestral snapshot.

[0021] Optionally, when the request type is the comparison or the first type of merging, the current version is the target version, and the content in the current version information area is the same as the corresponding content in the target version; when the request type is the second type of merging, the current version is the version obtained by updating the target version based on the reference version, and the content in the current version information area is the version obtained by updating the target version based on the comparison result.

[0022] Optionally, the content in the current version information area is obtained after updating the target version based on the comparison results, including:

[0023] Obtain the difference information between the reference version and the target version from the comparison results;

[0024] The difference information is validated using business rules.

[0025] The target version is updated based on the difference information verified by business rules.

[0026] Optionally, the step of comparing and analyzing each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version includes:

[0027] The assets are compared and analyzed based on their asset types in the asset data file to determine the comparison results of the reference version and the target version under different asset types. The asset types include any one or more of the following: text file, JSON file, and fixed-structure JSON.

[0028] In a second aspect, an electronic device is provided. The electronic device includes: one or more processors; and one or more memories coupled to the one or more processors and storing instructions thereon. When the instructions are executed individually or jointly by the one or more processors, the electronic device performs the method of the first aspect described above.

[0029] In a third aspect, a computer-readable medium is provided. Instructions are stored on the computer-readable medium that, when executed individually or jointly by at least one processor of an electronic device, cause the electronic device to perform the method of the first aspect described above.

[0030] Compared with existing technologies, this application has the following advantages: it provides a visual comparison and merging capability that is compatible with low-code assets. The display format of the comparison and merging results between versions (such as between the reference version and the target version) matches the display format during development. Through visualization, users can more intuitively understand the differences between versions and assist them in managing versions more quickly. Attached Figure Description

[0031] The accompanying drawings are included to provide a further understanding of this application; they are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application. In the drawings:

[0032] Figure 1 This is an exemplary flowchart of a software asset management method provided in an embodiment of this application;

[0033] Figure 2 This is a schematic diagram illustrating a scenario of cross-engineering version iteration provided in an embodiment of this application;

[0034] Figure 3 This is a schematic diagram of another visual page provided in an embodiment of this application;

[0035] Figure 4 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0036] Figure 5 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0037] Figure 6 This is a flowchart illustrating a comparison method provided in an embodiment of this application;

[0038] Figure 7 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0039] Figure 8 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0040] Figure 9 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0041] Figure 10 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0042] Figure 11 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0043] Figure 12 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0044] Figure 13 This is a schematic diagram of yet another visual page provided in the embodiments of this application;

[0045] Figure 14 This is a schematic diagram of an asset lineage provided in an embodiment of this application;

[0046] Figure 15This is a schematic diagram illustrating a scenario for finding a baseline version, provided in an embodiment of this application.

[0047] Figure 16 A simplified block diagram of an electronic device suitable for implementing exemplary embodiments of the present disclosure is shown. Detailed Implementation

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this application. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0049] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0050] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application. It should also be understood that, for ease of description, the dimensions of the various parts shown in the drawings are not drawn to actual scale. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0051] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0052] Low-code development is a software development methodology focused on rapidly building applications. Its core characteristics are:

[0053] Visual modeling: Replacing traditional code writing with graphical interfaces (such as drag-and-drop components and flowchart design) to achieve an intuitive expression of business logic and interface layout;

[0054] Pre-built modular components: Provides reusable standardized functional modules (such as forms, reports, and API interfaces), allowing developers to integrate functions through configuration rather than coding;

[0055] Model-driven logic: Centered on data models and business rules, it automatically generates the underlying code framework through declarative configuration (such as parameter settings and rule engines);

[0056] Minimal code expansion: Allows developers to supplement complex logic with scripts or custom components, but the amount of code is less than 20% of that in traditional development models.

[0057] Developers using low-code platforms typically don't need to possess the technical skills required for software development to complete the project, resulting in a lower technical barrier. Traditional version control tools (such as Git) primarily perform version merging and comparison by comparing and contrasting differences at the plain text or code level, and the comparison and merge results are presented accordingly. For developers using low-code platforms, lacking the underlying software development skills (e.g., no coding knowledge), it's difficult to understand the comparison and merge results output.

[0058] To alleviate the above problems, this application proposes a software asset management method that provides a visual comparison and merging capability compatible with low-code assets. The display format of the comparison and merging results between versions (such as between the reference version and the target version) matches the display format during development. Through visualization, developers can more intuitively understand the differences between versions and assist them in managing versions more quickly.

[0059] See Figure 1This application proposes a software asset management method applied to electronic devices, which can be servers or terminal devices. As an example and not a limitation, terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, VoIP phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop installed devices (LMEs), smart devices, wireless user equipment (CPEs), Internet of Things (IoT) devices, industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, relay nodes, and devices operating on commercial and / or industrial wireless networks. The software asset management method includes:

[0060] Step S10: Respond to the version commit requests for the reference version and the target version, and determine the operation version that matches the request type corresponding to the version commit request. The operation version includes the iterative version associated with the reference version and the target version, or the operation version includes the iterative version, the target version, and a common baseline version between the reference version and the target version. The request types include comparison, first-type merge, and second-type merge.

[0061] The aforementioned reference version and target version may belong to the same project or different projects. In one embodiment, to address this, the method further includes: detecting the iterative relationship between the reference version and the target version; when the iterative relationship is across projects (i.e., the reference version and target version belong to different projects), copying the reference version to obtain a mirror version of the reference version; unifying the asset identifier of the mirror version with that of the target version; and determining the mirror version with the unified asset identifier as the aforementioned iterative version. When the iterative relationship is within the same project (i.e., the reference version and target version belong to the same project), the reference version is determined as the iterative version, and subsequent electronic devices can perform version merging or comparison based on this iterative version. For example, assuming the reference version belongs to project A and the target version belongs to project B, the cross-project comparison process can refer to... Figure 2 As shown.

[0062] In one embodiment, the asset identifiers of the mirror version can be unified with those of the target version according to a pre-set unified resource identifier rule. For example, the unified resource identifier rule could be: for page-type assets, the page's routing address is used as its corresponding asset identifier; for logic-type assets, the path of the logic-type asset is used as its corresponding asset identifier, and so on. The specific rules can be pre-configured according to actual needs.

[0063] It is understandable that the unique IDs (i.e., the asset identifiers mentioned above) of each asset may differ in different software versions of different projects. Different unique asset IDs will prevent the comparative analysis in step S11 between two versions across projects, or affect the accuracy of the final comparative analysis results (such as the comparison results in step S11). Based on this, this embodiment of the application unifies the asset identifiers of the mirror version with those of the target version, and determines the mirror version with the unified asset identifiers as the aforementioned iterative version. This ensures that the asset identifiers of the iterative version and the target version are consistent, facilitating the subsequent comparative analysis between the two versions (the iterative version and the target version) across projects. In addition, since cross-project processing involves adjustments to the code level corresponding to the version (such as the asset identifiers mentioned above), creating a mirror version based on the reference version as the basis for subsequent comparative analysis can reduce modifications to the reference version and facilitate backtracking should any abnormalities occur in the subsequent processing.

[0064] In one embodiment, when the request type is comparison or merge, the operation version includes the iterative version and the target version; when the request type is automatic merge, the operation version includes the iterative version, the target version, and the baseline version.

[0065] For example, see Figures 3-5 The application scenario is as follows: After the first mainline version "S12-110" is released, the first mainline version's iteration ends. The first mainline version is copied to obtain the second mainline version "S12-112". Developers continue to develop new features based on the second mainline version. Meanwhile, some issues may occur after the release of the first mainline version "S12-110". To fix these issues, users can... Figure 3 In the iteration record shown, a branch version 1 "S12-113" is created through the "Create Branch" entry corresponding to the first mainline version "S12-110". Development continues in branch version 1 to fix the problem. Further, after the problem is fixed in branch version 1, the user wants to merge the updated content that fixed the problem into the second mainline version "S12-112" where new feature development is underway. In this case, the electronic device can output... Figure 3 The second main version iteration record page shown can be displayed on electronic devices in response to a "select comparison" trigger (suitable for users who only want to compare two versions). Figure 4 The operation object selection page shown uses this page to determine branch version 1 "S12-113" as the reference version and the second main line version "S12-112" as the target version. When the user clicks the "Confirm" button, the electronic device confirms that it has detected version submission requests for the reference version and the target version, and that the request type of the version submission request is comparison.

[0066] Alternatively, the electronic device can respond to a target Figure 3 The "Select Merge" trigger operation in the middle entry displays... Figure 5 The operation object selection page shown allows you to select branch version 1 "S12-113" as the reference version and the second main version "S12-112" as the target version. If the user does not check the box... Figure 5 In the "Automatically apply changes" section, click the "Confirm" button (applicable when the user wants to manually merge two versions in the current resource management system). The electronic device confirms that it has detected version submission requests for the reference version and the target version, and that the request type of the version submission request is a Type 1 merge.

[0067] Or, the user selects... Figure 5 In the "Automatically apply changes" section, click the "Confirm" button (applicable when the user wants to automatically merge two versions in the current resource management system). The electronic device confirms that it has detected version submission requests for the reference version and the target version, and that the request type of the version submission request is a Type II merge.

[0068] Step S11: Obtain the asset data file corresponding to the operation version, and perform comparative analysis on each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version.

[0069] In one embodiment, step S11 includes: performing a comparative analysis on each asset according to its asset type in the asset data file, and determining the comparison results of the reference version and the target version under different asset types. The asset types include any one or more of the following: text files, JSON files, and fixed-structure JSON, and the asset data file can be a JSON format data file.

[0070] In one embodiment, when the asset type is a text file, the Git Diff3 algorithm can be used for comparative analysis to determine the comparison results between the reference version and the target version for text file assets. When the asset type is a JSON file (such as some descriptive information), the comparison results between the reference version and the target version for JSON file assets can be determined by comparing whether the attribute values ​​of each asset are consistent. When the asset type is a fixed-structure JSON (such as a structured JSON with multiple components nested within a page), the comparison results can be determined by recursively calling the comparison method.

[0071] For example, assuming the operation version includes an iterative version, a target version, and a baseline version, the process of recursively calling the comparison method can be referred to Figure 6As shown, the process includes: collecting all keys (Keys) from the fixed-structure JSON in the asset data files of the iterative version, target version, and baseline version; iterating through each key and obtaining the corresponding value (Value); monitoring the changes in the value of each key across the three versions; and using the value changes as the comparison result. Assuming the operation versions include the iterative version and the target version, the recursive comparison method involves: collecting all keys (Keys) from the asset data files of the iterative version and the target version; iterating through each key and obtaining the corresponding value (Value); monitoring the changes in the value of each key across the two versions; using the value changes as the comparison result; and so on, until all keys have been iterated through.

[0072] It should be noted that when the operational version includes the iterative version, the target version, and the baseline version, the comparison results mainly represent the changes of the target version and the iterative version relative to the baseline version. Figure 6 For example, in the diagram, "No change on both sides" indicates that neither the target version nor the iterative version has changed relative to the baseline version; "Only the reference version has changed" indicates that only the reference version has changed relative to the baseline version; and "Only the target version has changed" indicates that only the target version has changed relative to the baseline version. When the operating version includes both the iterative version and the target version, the comparison results mainly represent the changes between the target version and the iterative version.

[0073] S12: Output the version iteration page corresponding to the current version that matches the request type. The version iteration page displays an asset tree list including at least one level node and a status identifier. The type and display position of the status identifier are determined based on the comparison results and the request type.

[0074] S13: In response to a view operation on any level node in at least one level node, output a reference version information area and a current version information area. The display format of the content in the reference version information area and the current version information area matches the development display format corresponding to any level node. The display format includes plain text, list format, or key-value pair format.

[0075] In one embodiment, the type and display position of the status identifier in step S12 are determined based on the comparison result and the request type. Specifically, when the request type is comparison or a first-type merge, the status identifier type may include change, addition, deletion, movement, etc. When the request type is a second-type merge, since automatic merging is involved, the status identifier type may additionally include: automatically processed, conflict, etc. In step S12, the comparison result indicates which part of the assets has changed, and the corresponding status identifier is displayed at the corresponding hierarchical node of that part of the assets.

[0076] In one embodiment, for a scenario where the user only wants to compare the reference version and the target version, the current version matching the request type in step S12 includes: when the request type is comparison, the current version is the target version, and the content in the current version information area is the same as the corresponding content in the target version.

[0077] For example, refer to Figure 4 and Figure 7 Users through Figure 4 The page selects branch version 1 "S12-113" as the reference version and the second main branch version "S12-112" as the target version, and submits a request type of "Comparison Version Submission Request" (for scenarios where the user only wants to compare the reference version and the target version). The electronic device can display as follows: Figure 7 The version iteration page shown includes an asset tree list 70 with at least one hierarchical node, and a status identifier (such as...). Figure 7 (e.g., "change", "move").

[0078] When a user wants to compare the differences between the reference version and the current version of a resource at any level node, they can touch the corresponding location in the asset tree list 70. This will trigger the electronic device to display the corresponding reference version information area and current version information area on the version iteration page. The content in the current version information area is the same as the corresponding content in the target version. For example, if the user touches the "Home" level node in the asset tree list 70 to input a viewing operation, the electronic device can display... Figure 8 The page shown displays content in key-value pairs; for example, if a user enters "JS abc" into the level node "70" of the asset tree list, the electronic device can display... Figure 9 The page shown displays the relevant content in plain text format; if the user enters a viewing operation by touching the "Global Logic" node in the asset tree list (level 70), the electronic device can display... Figure 10 The page shown displays the relevant content in a list format.

[0079] In one embodiment, for a scenario where a user wants to manually update the target version based on a reference version, the current version matching the request type in step S12 includes: when the request type is a first type of comparison, the current version is the target version, and the content in the current version's information area is the same as the corresponding content in the target version. Compared to the scenario of only comparing, the main difference is the addition of some merge-related operation buttons, making it easier for users to overwrite the current version with the changed parts in the reference version. For example, the reference version... Figure 11 ,compared to Figure 8 Add operation button , and These are used for operations such as manipulating overwritten content, undoing a merge, and completing a merge, as well as adding a partial overwrite button to the current version information area. Still with Figure 11 For example, the user operates the partial coverage button. The electronic device will overwrite the component properties of the button in the current version on the right with the component properties of the button in the reference version on the left. The component property content in the current version will be updated from "Button 1" to "Button 2", partially overwriting the button. The location will also update to display the "Undo Merge" button. ,like Figure 13 As shown, users can undo the update by clicking the "Undo Merge" button. This enables rollback.

[0080] In one embodiment, for a scenario where a user wants to automatically update the target version based on a reference version, the current version matching the request type in step S12 includes: when the request type is a second type of comparison, the current version is the version obtained after updating the target version based on the reference version, and the content in the current version information area is the version obtained after updating the target version based on the comparison result.

[0081] In one embodiment, the content in the current version information area is obtained by updating the target version based on the comparison results, including: updating the target version according to the automatic merging strategy and the comparison results. For example, the automatic merging strategy can be shown in Table 1:

[0082] Table 1

[0083] In one embodiment, the content in the current version information area is obtained by updating the target version based on the comparison results, including: obtaining the difference information between the reference version and the target version from the comparison results, performing business rule verification on the difference information, and updating the target version based on the difference information that has passed the business rule verification. The business verification rules are pre-configured and differ for different asset types. For example, if the business verification rule stipulates that the data model cannot be modified during branch development, in this case, if the target version is a branch version and the content to be automatically merged (i.e., the difference information) is the data model, then the difference information will be determined to have failed the business rule verification, resulting in a merge failure message. Otherwise, the difference information will be automatically merged and updated to the target version to obtain the current version. As another example, if the business verification rule stipulates that published interfaces cannot be taken offline, and an offline process must be followed before automatic merging, then if the content to be automatically merged (i.e., the difference information) is the content corresponding to the interface, and the automatic merging operation involves deleting this content from the target version, then according to the business verification rule, the corresponding automatic merging operation cannot be performed, the business verification rule will fail, and a merge failure message will be displayed.

[0084] As can be seen in this embodiment, assets during the comparison and merging process will have different types of status indicators, all of which can be displayed on the corresponding version iteration page (e.g., Figure 7 This helps users identify changes to assets, such as: Change: Differences exist between two versions during comparison; during merging, the baseline version is the same as one version but different from another. A reference version that matches the target version but differs from the baseline version will not be marked as "Change"; Conflict: During merging, the baseline version, reference version, and target version are all different; Move: The target version node's location is inconsistent with the reference version; Merge Failure: Merge failure may occur due to identifier conflicts or system anomalies; hovering over the node will display the reason for the anomaly; Processed.

[0085] "Processed" can be further categorized into the following situations: After manually clicking to complete the merge in the resource tree list, it will be marked as "Processed"; the content within the file (such as...) Figure 8 Once the content of the component properties is overwritten or the merge is completed, it will be marked as "processed"; in the resource tree list, files that are automatically merged by the system will be marked as "automatically processed by the system".

[0086] In one embodiment, the reference version information area further includes a version switching view entry, which is used to switch between viewing content associated with any of the reference version, target version, and baseline version nodes. This version switching view entry can be, for example, as shown below. Figure 8In section 80, users can use this button to switch between viewing the component properties corresponding to the buttons in the reference version, target version, and baseline version. This makes it easier for users to trace the source during the comparison and merging process and helps them determine the changes between the current version, target version, baseline version, and reference version.

[0087] In one embodiment, the display format of the content in the reference version information area and the current version information area in step S13 matches the development display format corresponding to any level node. This can be understood as follows: when the development display format of the resource corresponding to any level node is plain text, then the display format of the content in the reference version information area and the current version information area is also plain text; when the development display format of the resource corresponding to any level node is a list format, then the display format of the content in the reference version information area and the current version information area is also a list format; when the development display format of the resource corresponding to any level node is a key-value pair format, then the display format of the content in the reference version information area and the current version information area is also a key-value pair format. For example, developers developed the home screen page in the target version using low-code, and the development display format of this page is as follows: Figure 13 As shown, the component attributes of button 1 are displayed in key-value pair format. Accordingly, when the electronic device in this embodiment executes step S13, the display format of the content of button 1 in the reference version information area and the current version information area is the same as the corresponding development display format, such as... Figure 8 As shown.

[0088] In one embodiment, before performing step S11 to compare and analyze each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version, the method further includes: performing semantic analysis on each asset in the asset data file, and deleting data of a preset type from the asset data file based on the semantic analysis results. The preset type of data refers to pre-entered invalid comparison data, such as data representing the visibility state of an asset. For example, if data A is folded in the reference version and expanded in the target version, the folding or expansion of data A has no impact on the version's running result. If this invalid comparison data is not removed, on the one hand, the amount of data processed in subsequent comparison analysis will be larger; on the other hand, the introduction of this invalid comparison data will increase the time and effort required for users to manually verify or merge the comparison results. Therefore, this embodiment of the application first removes invalid comparison data that has no impact on resource operation through semantic analysis before performing formal comparison analysis, which helps to reduce the manpower required for some invalid comparisons.

[0089] In one embodiment, after responding to version commit requests for the reference version and the target version, the method further includes:

[0090] Step 1: From the pre-stored asset lineage, determine the most recent common ancestor version between the reference version and the target version, as well as the first and second timestamps of the lineage relationship between the reference version and the target version and the common ancestor version, respectively.

[0091] Step 2: Locate the ancestor snapshot of the common ancestor version in the distributed version control system corresponding to the target timestamp. The target timestamp is the earlier timestamp between the first timestamp and the second timestamp.

[0092] Step 3: Determine the baseline version based on the ancestor snapshot.

[0093] Among them, the aforementioned asset blood relationship can be, for example, as follows: Figure 14 As shown, each circle corresponds to a version. Each time a new version is added, iterated, copied, or merged, it is recorded in the resource lineage as a directed graph. For example, branch 1 "S12-113" is a branch created based on the main branch "S12-110". Correspondingly, a record is created in the asset lineage pointing from the main branch "S12-110" to branch 1 "S12-113", recording the timestamp and event content (such as branch creation). The aforementioned distributed version control system could be, for example, Git. This system is primarily used for version management; once a version is modified, a new node is added to record the content of the new version.

[0094] The following examples illustrate steps 1 through 3 above, using specific scenarios as examples. Figure 15The scenario is as follows: At time 1 (September 15, 2025), version 2 was created based on version 1 (content 1, 3, 5). At time 2 (September 16, 2025), version 1.1 was created based on version 1 (content 1, 3, 5) and some issues were fixed in version 1.1. At time 3 (September 18, 2025), the user wants to merge version 1.1 with version 2. At this time, the content of version 2 is 1, 3, 5, and the content of version 1.1 is 1, 2, 3, 5. The content of the baseline version has been updated from "content 1, 3, 5" at time 1 to "content 1, 2, 3, 4, 5". When it is necessary to find the common baseline version of version 1.1 and version 2, according to the known traditional method, the most recent common ancestor version of version 1.1 and version 2, "version 1", is searched as the common baseline version. However, the content corresponding to the current "version 1" has been updated and is not the true baseline content of version 1.1 and version 2, which will cause deviations in subsequent comparison and merging. To address this situation, the embodiments of this application can first locate the nearest common ancestor version "version 1" between the reference version and the target version from the resource lineage. In addition, the first timestamp (i.e., time point 1) and the second timestamp (i.e., time point 2) of the lineage relationship between version 2 and version 1.1 and the common ancestor version "version 1" can be obtained. Since time point 1 is earlier than time point 2, the ancestor snapshot of "version 1" at time point 1 is subsequently obtained from the distributed version control system, that is, the version content (content 1, 3, 5) of "version 1" at time point 1 is obtained, and it is used as the baseline version content between version 1.1 and version 2.

[0095] Figure 16 This is a simplified block diagram of an electronic device suitable for implementing embodiments of the present disclosure. For example, the software asset management method described above can be implemented by an electronic device. As shown, the electronic device includes one or more processors 160, one or more memories 161 coupled to the processors 160, and one or more communication modules 162 coupled to the processors 160.

[0096] Communication module 162 is used for bidirectional communication. Communication module 162 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0097] Processor 160 can be any type suitable for a local technology network, and as a non-limiting example, can include one or more of the following: general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures. Electronic devices can have multiple processors, such as application-specific integrated circuit (ASIC) chips, which are timely driven to a clock that synchronizes with the main processor.

[0098] Memory 161 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1610, electrically programmable read-only memory (EPROM), flash memory, hard disk, optical disc (CD), digital video disc (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1611 and other volatile memories that do not persist during power-off periods.

[0099] Computer program 163 includes computer-executable instructions that are executed by a associated processor 160. Program 163 may be stored in ROM 1610. Processor 160 may perform any appropriate actions and processes by loading program 163 into RAM 1611.

[0100] Embodiments of this disclosure can be implemented via program 163, enabling an electronic device to execute reference... Figure 1 Any process disclosed herein. Embodiments of this disclosure may also be implemented in hardware or by a combination of software and hardware.

[0101] In some embodiments, program 163 may be tangibly contained in a computer-readable medium, which may be contained in an electronic device (e.g., memory 161) or other storage device accessible to the electronic device. The electronic device may load program 163 from the computer-readable medium into RAM 1611 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Program 163 is stored on the computer-readable medium.

[0102] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while others may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other electronic device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or other graphical representations, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other electronic devices, or some combination thereof.

[0103] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the aforementioned references. Figure 1The method described herein. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or separated among program modules as needed. The machine-executable instructions used in the program module can execute on a local or distributed device. In a distributed device, the program module can reside on both local and remote storage media.

[0104] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, partially on a remote machine, partially on a remote machine, or entirely on a remote machine or server as a standalone software package.

[0105] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0106] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination thereof. More specific examples of computer-readable storage media include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0107] Furthermore, although the operations are described in a specific order, this should not be construed as requiring that these operations be performed in the specific order or sequence shown, or that all of the operations shown be performed to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these details should not be construed as limiting the scope of this disclosure, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0108] Although this disclosure has been described in language specific to structural features and / or methodological behavior, it should be understood that this disclosure as defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A software asset management method, characterized in that, The method includes: In response to version submission requests for a reference version and a target version, determine an operation version that matches the request type corresponding to the version submission request; the operation version includes an iterative version associated with the reference version and the target version, or the operation version includes the iterative version, the target version, and a baseline version common to the reference version and the target version; the request type includes comparison, first type merge, and second type merge. Obtain the asset data file corresponding to the operation version, and perform comparative analysis on each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version; Output the version iteration page corresponding to the current version that matches the request type. The version iteration page displays an asset tree list including at least one level node and a status identifier. The type and display position of the status identifier are determined according to the comparison result. One level node in the at least one level node corresponds to one or more assets. In response to a viewing operation on any of the at least one level nodes, a corresponding reference version information area and a current version information area are output. The display format of the content in the reference version information area and the current version information area matches the development display format corresponding to the any level node. The display format includes plain text, list format, or key-value pair format.

2. The method as described in claim 1, characterized in that, Before performing comparative analysis on each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version, the method further includes: Semantic analysis is performed on each asset in the asset data file, and data of a preset type is deleted based on the semantic analysis results.

3. The method as described in claim 1, characterized in that, The reference version information area also includes a version switching view entry, which is used to switch between viewing content associated with any of the level nodes in the reference version, the target version, and the baseline version.

4. The method as described in claim 1, characterized in that, After the response submits a version request for both the reference version and the target version, the method further includes: Detect the iterative relationship between the reference version and the target version; When the iteration relationship is across projects, the reference version is copied to obtain a mirror version of the reference version, the asset identifier of the mirror version is unified with the target version, and the mirror version with unified asset identifier is determined as the iteration version; When the iteration relationship is the same project, the reference version is determined as the iteration version.

5. The method as described in claim 1, characterized in that, After the response submits a version request for both the reference version and the target version, the method further includes: From the pre-stored asset lineage, determine the nearest common ancestor version between the reference version and the target version, as well as the first and second timestamps of the reference version and the target version that are related to the common ancestor version, respectively; Locate the ancestor snapshot of the common ancestor version at the target timestamp from the distributed version control system. The target timestamp is the earlier of the first timestamp and the second timestamp. The baseline version is determined based on the ancestral snapshot.

6. The method as described in claim 1, characterized in that, When the request type is the comparison or the first type of merging, the current version is the target version, and the content in the current version information area is the same as the corresponding content in the target version; when the request type is the second type of merging, the current version is the version obtained by updating the target version based on the reference version, and the content in the current version information area is the version obtained by updating the target version based on the comparison result.

7. The method as described in claim 6, characterized in that, The content in the current version information area is obtained by updating the target version based on the comparison results, including: Obtain the difference information between the reference version and the target version from the comparison results; The difference information is validated using business rules. The target version is updated based on the difference information verified by business rules.

8. The method as described in claim 1, characterized in that, The step of comparing and analyzing each asset in the asset data file to determine the comparison results corresponding to the reference version and the target version includes: The assets are compared and analyzed based on their asset types in the asset data file to determine the comparison results of the reference version and the target version under different asset types. The asset types include any one or more of the following: text file, JSON file, and fixed-structure JSON.

9. An electronic device, comprising: Memory is used to store instructions that can be executed by the processor; and a processor for executing the instructions to implement the method as described in any one of claims 1-8.

10. A computer-readable medium storing computer program code that, when executed by a processor, implements the method as claimed in any one of claims 1-8.

Images