Multistage classified management patch system

Abstract

The invention provides a multilevel classification management patch system, which belongs to the technical field of patch classification management, and comprises the following steps that: classification is added on patch information, the classification attribute of the added classification refers to a set of classification related information, and the classification attribute comprises the following information: a classification ID (Identity), a patch classification description and a patch classification identifier; the multi-stage classified management patch system can be used for creating, updating, deleting, querying and combining classifications. The patch supports a classification branch relation formed according to multi-level classification, so that problems can be conveniently analyzed and searched; the software patches can be split into a plurality of classified patches according to classification attributes, so that the conflict problem of patch backspacing can be conveniently solved; software versions can be published according to classified snapshots; and a multi-branch system is combined according to classification attributes and classification branch lines, so that the workload of full-branch combination is reduced.

Description

Technical Field

[0001] The present invention relates to software patches, and in particular to a patch management system, belonging to the technical field of patch classification management. Background Art

[0002] Currently, patches are basically managed by submitting them according to time and creating branches. A typical patch system management diagram is as Figure 1 shown. There are branches master and feature, and patches are submitted in chronological order on the same branch. Software repository management systems such as Git or svn have achieved great success. Thousands of developers have developed many excellent software through the repository system. However, the current Git-based software repository management still has the following pain points:

[0003] 1. The classification of patches is not unified: Patches are classified by developers manually filling in the title, which is not unified, not mandatory, and not standardized, resulting in difficulties in searching and analyzing; It is particularly cumbersome to search for patches for a certain problem, especially when some patch submission information is written non-standardly.

[0004] 2. The function modules and scenario selection are complex: By using branches or manually configuring function modules (such as menuconfig), it leads to too many branches or cumbersome configuration; Branch explosion and software function customization are troublesome, lacking an automatic mapping function and a patch management tool.

[0005] 3. Branch merging is complex: Conflicts are likely to occur when multiple branches are merged, and patches on different branches affect each other; Conflicts occur frequently during merging, and manual resolution is time-consuming and error-prone. Summary of the Invention

[0006] In view of the above problems, the present invention provides a multi-level classification management patch system.

[0007] To achieve the above object, the technical solution of the present invention is: A multi-level classification management patch system, including a classification management tree, a software patch repository, and a classified patch repository;

[0008] The classification management tree manages the information of each classification. Each classification includes corresponding classification attributes, and the classification attributes refer to the set of classification-related information; The classification attributes include the following information: classification ID, patch classification description, classification identifier of the patch; The patch classification description includes classification name, classification function description, classification content, description of the parent-child relationship, and description of the sub-class relationship; The classification identifier of the patch refers to the identifier of the classification attributes of the patch;

[0009] The software patch repository is a repository that arranges software patches according to the submission time; The classified patch repository is a repository that projects each patch in each software patch onto the corresponding classification category of the classification management tree to generate classified patches, and arranges the classified patches according to the classification category and submission time;

[0010] The multi-level classification management patch system can perform operations such as creation, update, deletion, query, and merging of classifications, so as to realize the update, deletion, query, and merging of patches;

[0011] The creation of a classification in the classification management tree includes the following steps:

[0012] (1) Users or administrators add the required classifications to the classification management tree according to the requirements of patch classification. The system applies for a matching classification ID and defines the classification name, classification function description, and classification content according to the needs of users or administrators; if the classification ID cannot be applied for, it will display that the classification creation fails, otherwise it will enter the next step;

[0013] (2) The system searches for parent classes in the classification management tree one by one according to the classification function description and classification content of the newly added classification. If more than two parent classes are found, it will display that the classification creation fails. If not, it will enter the next step;

[0014] (3) If one parent class is found, the classification will be created as a subclass under this parent class. The parent class contains a subclass pointer, and the subclass contains a parent class pointer;

[0015] (4) After the above classification branch relationship is divided, update the classification patch repository according to the content of the latest classification management tree.

[0016] Furthermore, the update of the classification patch repository in the classification creation step is carried out as follows:

[0017] a. The user initiates a command to update the classification patch repository;

[0018] b. Abolish the previous classification patch repository;

[0019] c. Extract software patches from the software patch repository one by one, split the software patches into classification patches according to the classification content of each level of classification in the classification management tree, submit the classification patches to the corresponding positions in the classification patch repository, and assign a classification patch ID to the classification patch. The classification patch ID is the software patch ID + classification ID;

[0020] d. Display that the classification patch repository is updated to the update state after extraction.

[0021] Furthermore, the deletion of a classification in the classification management tree is carried out as follows:

[0022] (1) The user initiates a command to delete a classification;

[0023] (2) Search for the classification in the classification management tree according to the classification ID to be deleted. If the classification ID to be deleted is not found, it will display that the classification deletion fails. If not, it will enter the next step;

[0024] (3) Delete the corresponding classification in the classification management tree, and delete the pointer address of this classification in the classification attributes of its parent class and subclasses;

[0025] (4) Update the classification patch repository according to the content of the latest classification management tree.

[0026] Furthermore, the steps to update the classification patch repository after deleting a classification in the classification management tree are as follows:

[0027] a Extract classification patches from each branch in the classification patch repository;

[0028] b Extract the corresponding classification ID from the classification patch ID of the extracted classification patches;

[0029] c Match the classification ID with the classification ID of the deleted classification;

[0030] d If the match is consistent, delete the corresponding classification patch from the classification patch repository.

[0031] Furthermore, the multi-level classification management patch system can also perform the rollback of software patches, and the steps are as follows:

[0032] A The user initiates a rollback to a certain software patch;

[0033] B Match the software patch ID in the software patch repository. If the software patch ID cannot be found, display that the rollback patch fails. If the software patch ID is found, proceed to the next step;

[0034] C Delete the software patches whose submission time is after the matched software patch;

[0035] D Roll back the classification patches corresponding to the deleted software patches in the classification patch repository.

[0036] Furthermore, the multi-level classification management patch system can also perform the rollback of classification patches, and the steps are as follows:

[0037] A The user initiates a rollback to a certain classification patch;

[0038] B Match the corresponding classification patch ID in the classification patch repository. If the classification patch ID cannot be found, display that the rollback of the classification patch fails. If it is found, proceed to the next step;

[0039] C Delete all classification patches of the same classification after the classification patch submission time corresponding to this classification patch ID from the classification patch repository;

[0040] D Match the patches corresponding to this classification patch from the software patches in the software patch repository, and delete the matched patches.

[0041] Furthermore, the multi-level classification management patch system can also perform queries on classifications, patches, and classification patches, and the steps are as follows:

[0042] (1) Method for finding a classification in the classification management tree:

[0043] A. The user initiates a command to find a classification;

[0044] B. Match the classification ID in the classification management tree file. If the classification ID cannot be found, display that the classification query fails. If found, proceed to the next step;

[0045] C. Locate the classification item and list the classification-related information;

[0046] (2) Method for querying a patch:

[0047] A. The user initiates a query to a certain patch;

[0048] B. Match the software patch ID, name, or author in the software patch repository. If not found, display that the patch query fails. If found, proceed to the next step;

[0049] C. Display the content of the patch;

[0050] (3) Method for querying a classification patch:

[0051] A. The user initiates a query to a certain classification patch;

[0052] B. Match the classification patch ID in the classification patch repository. If not found, display that the classification patch query fails. If found, proceed to the next step;

[0053] C. Display the content of the classification patch.

[0054] Furthermore, the multi-level classification management patch system can also perform classification merging, and the classification merging includes classification patch merging and branch classification merging. The steps for the classification patch merging are as follows:

[0055] (1) Arrange the classification patches in a column according to time, and the classification patch ID = software patch ID + classification ID;

[0056] (2) Compare the software patch IDs of adjacent classification patches, and stack and merge the content of the same software patch ID into one software patch;

[0057] (3) After the merging is completed, change the classification patch ID to the software patch ID and form a software patch repository in the order of submission time.

[0058] Furthermore, the steps for the branch classification merging are as follows:

[0059] (1) Generate a classification patch repository for the two branches to be merged according to the classification;

[0060] (2) Using the merged branch as the baseline, add different classified patches of the incorporated branch to the baseline branch;

[0061] (3) Reassign the baseline repository software patch ID to the newly incorporated classified patch to generate a new classified patch ID;

[0062] (4) Handle merge conflicts;

[0063] (5) Re - synthesize the classified patches after conflict handling into software patches and generate a new software patch repository.

[0064] The beneficial effects of a multi - level classification management patch system of the present invention are as follows:

[0065] The patch system of the present invention supports the formation of a classified branch relationship by classifying patches at multiple levels, facilitating the analysis and problem - finding; software patches can be "split" into multiple classified patches according to classification attributes, facilitating the resolution of conflicts in patch rollback; the present invention supports the release of software versions according to classified snapshots; the present invention also supports the merging of multi - branch systems according to classification attributes and classified branches, reducing the workload of full - branch merging. Description of the Drawings

[0066] The present invention will be further described in detail below with reference to the drawings and specific embodiments.

[0067] Figure 1 is a management diagram of a typical existing patch system;

[0068] Figure 2 is a structural diagram of the multi - level classification management patch system of the present invention;

[0069] Figure 3 is a schematic diagram of the multi - level classification management patch system of the present invention divided according to classification content;

[0070] Figure 4 is a creation step diagram of the classification of the present invention;

[0071] Figure 5 is a step diagram for deleting the classification of the present invention;

[0072] Figure 6 is a step diagram for updating the classified patch repository of the present invention;

[0073] Figure 7 is a projection example diagram of the present invention classified by 0;

[0074] Figure 8 is a schematic diagram of the method steps for rollback of the present invention;

[0075] Figure 9 is a schematic diagram of the method for finding classifications of the present invention;

[0076] Figure 10 It is a schematic diagram of the method for querying classification patches of the present invention;

[0077] Figure 11 It is an example diagram of the merger of classification patches of the present invention;

[0078] Figure 12 It is an example diagram of the merger of classification branches of the present invention;

[0079] Figure 13 It is an example diagram of the snapshot of patch labels of the present invention. Detailed implementation manners

[0080] The following describes clearly and completely the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar extensions without departing from the connotation of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed below.

[0081] Embodiment 1 Structure composition of a multi-level classification management patch system

[0082] Define the following noun definitions:

[0083] Patch: Refers to a file formed by modifying information of a software system, recording the set of files modified, deleted, and added in a software repository;

[0084] Software patch repository: A repository that arranges software patches according to the submission time of users. Multiple patches for the same software are regarded as one software patch, and multiple patches for multiple software form a software patch repository;

[0085] Classification patch: A component patch formed by projecting software patches onto corresponding classification categories according to the classification content of each patch. In other words, it is a patch formed after adding the classification management content (characterized by the ID of the corresponding classification) to the patch;

[0086] Classification patch repository: A repository that arranges classification patches according to classification categories and submission time;

[0087] Basic classification: The most primitive classification of the patch basis, by default including the management of all content, and newly added classifications default to belong to the basic classification;

[0088] Classification attribute: A set of information related to patch classification;

[0089] First-level classification: The first-level classification defined by the user;

[0090] Classification level: The basic classification level is 0, the first-level classification is 1, and so on.

[0091] The structure of the multi-level classification management patch system is as follows Figure 2 shown. The multi-level classification management patch system includes three parts: a classification management tree, a software patch repository, and a classified patch repository. Specifically,

[0092] the classification management tree manages the information of each classification. The classification management tree divides the classification levels according to classification attributes. The classification management tree is a framework without patches. The classification basis (hierarchical division) of the classification management tree is customized according to user needs. For example, multi-level classification can be performed according to the application object of the patch or the function of the patch. Specifically, a class of patches for the recording function can be classified and managed. This classification can be flexible and variable. The purpose is to classify the patches according to the hierarchical division of the classification management tree based on the created framework in the later stage. As Figure 2 shown in [figure], the basic classification 0 includes first-level classifications 1, 2, and 3. The first-level classification 1 further includes a second-level classification 1B (the first-level classification 1 is the parent class of the second-level classification 1B, and the second-level classification 1B is the subclass of the first-level classification 1. The same explanation applies below). The first-level classification 2 further includes second-level classifications 2C and 2D. After each level of the classification management tree is created, a unique classification ID will be matched to each level. This classification ID is an 8-bit hash value. For example Figure 2 the first-level classifications 1, 2, and 3, the second-level classifications 1B, 2C, and 2D in [figure] all correspond to a unique classification ID.

[0093] Figure 2 In [figure], p0, p1, p2, p3, p4, p5, p6 in the software patch repository represent each software patch; in the classified patch repository, in each schematic box, p0, p1, p2, p3, p4, p5, p6 in the upper row still represent each software patch, while 0, 1, 2, 3 in the lower row represent the categories of each patch among these software patches. Patches with the same number belong to the same classification level in the classification management tree. That is to say, the classified patch repository essentially "fissions" each patch in each software patch in the software patch repository, and divides the patches belonging to the same classification level in the order of submission time in the same branch, thus forming the classified patch repository.

[0094] Each classification in the classification management tree contains corresponding classification attributes. The classification attributes refer to the set of classification-related information, specifically including the following information: classification ID, patch classification description, classification identifier of the patch; the patch classification description includes classification name, classification function description (describing the classification function in words), classification content (defining the file scope managed by each level of the classification management tree), description of the parent-child relationship, and description of the sub-child relationship; the classification identifier of the patch refers to the identifier of the classification attributes of the patch, and the classification identifier of the patch is Figure 2In the classification management tree, 1B, 2C, 2D, etc. For example, in 1B, 1 represents the level and B represents the name, indicating the 1st level B classification. Checking the 1B classification patch can be reflected in the patch content as the 1B classification.

[0095] Table 1 Description of the classification storage items of the classification management tree file

[0096]

[0097] The software patch repository is a repository that arranges software patches according to the submission time. Multiple patches for the same software are regarded as one software patch, and multiple patches for multiple software form a software patch repository; the classification patch repository is a repository that projects each patch in each software patch onto the corresponding classification category according to the classification content of the patch and arranges the classification patches according to the classification category and submission time.

[0098] When the content of the software is modified, patches are formed. Each patch belonging to the same software has the same and only one software patch ID (i.e., commitid, the mother patch ID), which is a 40-bit hash value. This software patch ID can distinguish each software patch in the software patch repository. After the classification management tree is created, each patch is mapped and placed into each level, that is, the patches are classified (implemented by adding a classification attribute to the patch information) to form classification patches. The classification patches also have a dedicated ID, that is, the classification patch ID. The classification patch ID = software patch ID + classification ID, that is, the classification patch ID in the classification patch repository is a 48-bit hash value; the set of classification patches is the classification patch repository. That is, this 48-bit hash value is assigned to each patch during the process of "fission" of the software patch to form the classification patch repository.

[0099] Patches form a classification branch relationship according to the multi-level classification defined by the classification management tree. For example Figure 2 As shown in the classification management tree, the first-level classifications 1, 2, and 3 are equivalent to the classification branches of the basic classification 0. The second-level classification 1B is equivalent to the classification branch of the first-level classification 1, and the second-level classifications 2C and 2D are equivalent to the classification branches of the first-level classification 2; the multi-level classification management patch system can perform operations such as creation, update, deletion, query, and merger of classifications to achieve multi-level classification management of patches, that is, to achieve operations such as update, deletion, query, and merger of patches.

[0100] In addition, the logic for creating or updating the classification management tree by the multi-level classification management patch system according to the classification attribute is as Figure 3 shown as follows:

[0101] 1. By default, the basic classification 0 is defined to manage all patches. The patches newly added by the multi-level classification management patch system belong to the basic classification 0 by default;

[0102] 2. New categories can be created, and their classification attributes can be defined. At the same time, operations such as adding, deleting, modifying, and querying categories are supported.

[0103] 3. A subcategory cannot have two parent categories. For example, subcategory BA of category II cannot have some classification attributes belonging to category B of category I and some other classification attributes belonging to category C of category I.

[0104] 4. Each classification attribute belongs to a unique category. Classification attributes with overlap belong to the highest-level category. For example: If file attribute Z belongs to the intersection of category B of category I and subcategory BA of category II at the same time, then Z is managed by subcategory BA of category II; if Z only belongs to category B of category I and does not belong to subcategory BA of category II, then Z belongs to category B of category I.

[0105] Update of the patch system for creating, deleting, and multi-level classification management of categories in Embodiment 2

[0106] Based on Embodiment 1, the creation of categories is carried out according to the following steps. The specific steps are as Figure 4 shown:

[0107] (1) Users or administrators add the required categories in the category management tree according to the requirements for patch classification. The system will apply for a matching category ID (8-bit hash value) and define the category name, category function description, and category content according to the needs of users or administrators. If the category ID cannot be applied for, it will display that the category creation fails. Otherwise, it will enter the next step;

[0108] (2) The system searches for parent categories in the category management tree one by one according to the category function description and category content of the newly added category. If more than two parent categories are found, it will display that the category creation fails. If not, it will enter the next step;

[0109] (3) If one parent category is found, the category will be created as a subcategory under this parent category. The parent category contains a subcategory pointer (pointing to the subcategory address), and the subcategory contains a parent category pointer (pointing to the parent category address);

[0110] After the category creation is successful, the corresponding classification attributes of the category (at this time, the classification attributes do not have the parent category pointer address and the subcategory pointer address) are written into the category management tree, and at the same time, the classification attributes of this category and the parent category and / or subcategory corresponding to this category in the category management tree are updated: Specifically, the parent category pointer address and the subcategory pointer address in the classification attributes of this category and the parent category and / or subcategory corresponding to this category in the category management tree are updated;

[0111] If a subcategory, i.e., secondary category 2E, is created under primary category 3, after writing the classification attributes of secondary category 2E into the classification management tree, it is also necessary to write the pointer address of its parent category (i.e., primary category 3) into the classification attributes of secondary category 2E. Meanwhile, the pointer address of its subcategory (i.e., the newly added secondary category 2E) should be written (or added) into the classification attributes of primary category 3. If secondary category 2E still has subcategories in the classification management tree, the pointer addresses of its subcategories also need to be written into the classification attributes of secondary category 2E;

[0112] (4) After the above classification branch relationships are divided, the classification patch repository must be updated according to the content of the latest classification management tree.

[0113] Based on Example 1, the deletion of classification is carried out as follows, referring to Figure 5 as shown:

[0114] (1) The user initiates a command to delete a classification;

[0115] (2) Search for the classification in the classification management tree according to the classification ID to be deleted. If the classification ID to be deleted is not found, it is shown that the deletion of the classification fails. If not, proceed to the next step;

[0116] (3) Delete the corresponding classification in the classification management tree, and delete the pointer address of this classification in the classification attributes of its parent category and subcategories;

[0117] (4) Update the classification patch repository according to the content of the latest classification management tree as needed.

[0118] Furthermore, the update described in step (4) of the above two operations of classification creation and deletion can be configured by the multi-level classification management patch system to be automatically updated or manually updated.

[0119] When the multi-level classification management patch system is configured for automatic update, the system will automatically synchronously update and generate a new classification patch repository based on the software patch repository and the updated classification management tree. If the system is configured for automatic update, the system extracts each patch from the software patches submitted by the user, matches the attributes of each patch with the classification function descriptions and / or classification contents in the classification attributes corresponding to each level of classification in the classification management tree, "fissions" each patch in the software patches, divides the patches belonging to the same classification level into the same branch according to the submission time, and the multiple formed branches together constitute the classification patch repository. In this way, the classification patch repository will be updated in real time, but it will take time, especially when the repository is very large, the time consumption will be more.

[0120] When the multi-level classification management patch system is configured for manual update, when updating the classification management tree or the software patch repository, the multi-level classification management patch system will first mark the classification patch repository as the dirty state and then update the classification patch repository when necessary. Specifically, the update steps and methods of the multi-level classification management patch system are as Figure 6 shown:

[0121] Mark the classification patch repository as the dirty state when configured for manual update: When the user creates a classification management tree, deletes or adds a classification in the classification management tree, or when the user submits a software patch, rolls back a software patch, or rolls back a classification patch, first modify the classification patch repository to the dirty state; Method for updating the classification patch repository:

[0122] (1) Method for updating the classification patch repository after creating a new classification:

[0123] a The user initiates a command to update the classification patch repository;

[0124] b Abolish the previous classification patch repository;

[0125] c Extract software patches one by one from the software patch repository, split the software patches into classification patches according to the classification content of each level of classification in the classification management tree, submit the classification patches to the corresponding positions in the classification patch repository, and assign a classification patch ID to the classification patch. The classification patch ID is the software patch ID + classification ID;

[0126] Specifically, it includes the following steps:

[0127] c1: Extract patches one by one from the software patch, that is, extract the modified files:

[0128] For example, in the software patch submitted by the user, files a, b, c, and d have been modified, and according to the content submitted by the user, the set of file a and file b is one patch, and the set of file c and file d is another patch. Then, when extracting this software patch, two patches will be extracted. Next, the classification to which these two patches belong needs to be found;

[0129] c2: Match the attributes of the extracted patches with the classification function descriptions and / or classification contents in the classification attributes corresponding to each level of classification in the classification management tree:

[0130] If no match is found, it means that there is no classification for this patch in the classification management tree. At this time, a new classification will be created for this patch according to the method of creating the above classification; after creation, the classification patch repository will be updated again at an appropriate time based on manual or automatic configuration;

[0131] If a match is found, based on the software patch to which this patch belongs and the matched classification, assign a 48-bit classification patch ID to this patch and execute c3; where the classification patch ID consists of the 40-bit software patch ID corresponding to the software patch to which the patch belongs and the 8-bit classification ID corresponding to the matched classification in the classification management tree;

[0132] c3: According to the matched classification and the submission time of the software patch to which the patch belongs, add the extracted patch to the corresponding position in the classification patch repository;

[0133] c4: End after all patches are extracted.

[0134] d Display that the classification patch repository is updated to the update state after extraction.

[0135] (2) Method for updating the classification patch repository after deleting a classification:

[0136] Extract classification patches one by one from each branch in the classification patch repository;

[0137] Extract the corresponding classification ID from the classification patch ID of the extracted classification patch;

[0138] Match the classification ID with the classification ID of the deleted classification;

[0139] If the match is consistent, delete the corresponding classification patch from the classification patch repository.

[0140] The classification patch repository can also be updated using the following method:

[0141] After deleting a certain classification, the classification patch repository can be abolished first, and then each software patch in the software patch repository can be split into classification patches again to update the classification patch repository.

[0142] (3) Method for updating the classification patch repository when submitting or deleting a patch:

[0143] In this case, the classification management tree is not updated, only the patches are added or deleted: when the user submits or deletes a patch, as Figure 7 shown in the projection example of classification 0, when the user submits or deletes a patch, it is not necessary to abolish the previous classification patch repository as a whole. The classification patch repository can be updated by simply adding and deleting the corresponding classification patches in the classification patch repository.

[0144] Example 3 Rollback of software patches and classification patches

[0145] Rollback classification patch refers to deleting the classification patches after the submission time of the classification patches to be rolled back in the branch where the classification patch repository belongs, and at the same time deleting the corresponding patches in the software patch.

[0146] Rollback software patch refers to deleting other software patches after the submission time of the software patch from the software patch repository, and at the same time updating the corresponding classification patch repository. Specifically, as Figure 8 shown:

[0147] (1) Rollback to software patch:

[0148] User A initiates a rollback to a certain software patch. The rollback is an operation related to git reset. In the same software patch, if there are patches b1, b2, b3, b4 in chronological order, rolling back b2 means deleting b2, b3, and b4;

[0149] User B matches the software patch ID in the software patch repository. If the software patch ID cannot be found, it shows that the rollback patch fails. If the software patch ID is found, it proceeds to the next step;

[0150] User C deletes the software patches after the submission time of the matched software patch and the matched software patch. The matching method is to compare the commitid field;

[0151] User D rolls back the classification patches corresponding to the deleted software patches in the classification patch repository. That is, for example, for patches b1, b2, b3, b4, they are split into b1 / 0, b2 / 0, b3 / 0, b4 / 0 (classification 0) and b1 / 1, b2 / 1, b3 / 1, b4 / 1 (classification 1) according to classification 0 and classification 1. If rolling back b2, then b3 / 0 and b4 / 0 (classification 0) need to be deleted in the classification patch repository;

[0152] Through the above steps, the classification patches are deleted, the software patch repository is updated, and at the same time the classification patch repository is updated.

[0153] (2) Rollback to classification patch:

[0154] User A initiates a rollback to a certain classification patch;

[0155] User B matches the corresponding classification patch ID in the classification patch repository. If the classification patch ID cannot be found, it shows that the rollback classification patch fails. If found, it proceeds to the next step;

[0156] User C deletes all the classification patches of the same classification after the submission time of the classification patch corresponding to the classification patch ID from the classification patch repository;

[0157] D matches the patches corresponding to the classified patches one by one from the software patches in the software patch repository, deletes the matched patches, and the matching method is to extract the commitid field from the classified patch ID of the classified patch and compare it with the commitid field of the software patch;

[0158] By deleting the classified patches through the above steps, the classified patch repository is updated, and at the same time, the software patch repository is updated.

[0159] Example 4 Query of Classification, Patch and Classified Patch

[0160] On the basis of Example 3, the query of classification, patch and classified patch is carried out according to the following steps, referring to Figure 9 and Figure 10 as shown:

[0161] (1) Method for finding a classification in the classification management tree:

[0162] A The user initiates a command to find a classification;

[0163] B Matches the classification ID in the classification management tree file. If the classification ID cannot be found, it shows that the query for the classification fails. If it is found, proceed to the next step;

[0164] C Finds the classification item and lists the classification-related information.

[0165] (2) Method for querying a patch

[0166] A The user initiates a query to a certain patch;

[0167] B Matches the software patch ID or name or author in the software patch repository. If it cannot be found, it shows that the query for the patch fails. If it is found, proceed to the next step;

[0168] C Displays the content of the patch.

[0169] (3) Method for querying a classified patch (figure not shown):

[0170] A The user initiates a query to a certain classified patch;

[0171] B Matches the classified patch ID in the classified patch repository. If it cannot be found, it shows that the query for the classified patch fails. If it is found, proceed to the next step;

[0172] C Displays the content of the classified patch.

[0173] Example 5 Merging of Classifications

[0174] On the basis of Example 4, referring to Figure 11 and Figure 12 , the merging of classifications includes the merging of classified patches and the merging of branch classifications, where

[0175] The merging step of the classified patches is to merge the patches belonging to the same software in the classified patch repository, and generate a software patch repository according to the classified patch repository. Specifically, the merging of the classified patches is carried out as follows:

[0176] (1) Arrange the classified patches in a column according to time. The classified patch ID = commitid (software patch ID) + classification ID;

[0177] (2) Compare the commitids of adjacent classified patches. The content with the same commitid is merged into one software patch (the commitids of the classified patches belonging to the same software are the same);

[0178] (3) After the merging is completed, change the classified patch ID to commitid (software patch ID), that is, remove the classification ID, and form a software patch repository in the order of submission time.

[0179] Furthermore, for the case where there may be conflicts between some software patches in the branch classification merging, as Figure 12 shown, since the software patch p1 has divided into the line from b0 to b7, in this case, there may be a situation where the commitids (software patch IDs) of the software patches in the line p1 - p7 and the line b0 - b7 are the same. In this case, the classified patch IDs of the classified patches in these two branches will also be the same, resulting in management chaos. To prevent this situation, for relatively important classifications, it is necessary to merge the patches belonging to different software patches corresponding to this classification into the same branch in the classified patch repository, and re - classify the commitids (software patch IDs) of the classified patches in this branch to avoid the above situation.

[0180] Figure 12 In, the classification represented by "D" is the classification concerned in this embodiment. Therefore, it is necessary to merge the two branches corresponding to the "D" classification, and the steps are as follows:

[0181] (1) Generate a classified patch repository for the two branches to be merged according to the classification. As Figure 12 shown, the software patch repository divides into two branches (main branch and fest branch) from the patch p1. Since these two branches are both branched from p1, the software patch IDs of the patches in the two branches may overlap. The software patch IDs of all p branches do not overlap, and the software patch IDs of all b branches do not overlap either; the generated classified patch repository is such that the main branch splits into two classification branches of classification 0 and classification D, and the fest branch splits into two classification branches of classification 0 and classification D;

[0182] (2) Using the merged branch as the baseline (this baseline refers to arranging patches in chronological order at a certain classification level, such as the main branch), add different classification patches of the merged branch (the fest branch) to the baseline branch; for example, in the example, b1, b3, and b7 in classification D of the fest branch are merged after p7 in classification D of the main branch in chronological order because they have the same classification level as classification D of the main branch;

[0183] (3) Reassign the baseline repository commitid to the newly merged classification patches to generate new classification patch IDs; when b1, b3, and b7 in classification D of the fest branch are merged after p7 in classification D of the main branch, software patch IDs need to be reapplied (the baseline represents the main branch. Since there may be a situation where the software patch IDs of a certain patch in the fest branch and the main branch are the same, resulting in, for example, b1 / D, b3 / D, and b7 / D in the merged fest being regarded as components of a certain patch in the main branch, ultimately causing chaos in software patch ID management. Therefore, b1 / D, b3 / D, and b7 / D all need to reapply for the main branch software patch ID); similarly, if classification 0 is also a classification concerned in the present invention, b1 - b7 in classification 0 of the fest branch also need to be merged in the same way behind classification 0 of the main branch and also need to reapply for software patch IDs;

[0184] (4) Handle merge conflicts. Taking the baseline as the standard, discard the modified conflict parts of the merged patches, and also support manual editing by the user to modify merge conflicts; the content of each classification patch merged into the baseline may overlap or conflict with the content of each classification patch in the baseline. The same or conflicting content parts need to be deleted, that is, the content of the classification patches merged into the baseline will change compared with before merging;

[0185] (5) Re - synthesize the classification patches after handling conflicts into software patches and generate a new software patch repository.

[0186] Such as Figure 12 , for branches fest and main, do not merge all. Just merge the content of classification D from base class 0(0) to split out a classification D (covering the content to be merged) by classification.

[0187] Method for snapshot of classification version in Embodiment 6 (release version)

[0188] Based on Embodiment 5, the system further includes a classification version snapshot. An example of a patch label snapshot is as Figure 13 shown, and store the marked classification patch of each classification as a snapshot of the software version.

[0189] The classification patch snapshot is mainly used to mark the stable version state of the software or to make the software submitted for testing. The main features are as follows:

[0190] 1. The classification marking points of the version snapshot are flexible and variable;

[0191] 2. The version snapshot is stored in the form of a file, and the classified marking point set (referring to the set of each classification patch ID) and the classification management tree file are written into the snapshot file;

[0192] 3. A software repository supports multiple version snapshots, and each snapshot file has a unique identifier and name;

[0193] 4. When releasing software, first split the software patch repository into classified patch repositories, and each classified patch is rolled back to the snapshot marking point, then the version software production can be completed.

[0194] The main advantage of the version snapshot is that there is no need to wait for all problems in all classifications to be solved before releasing the software. Before releasing the software, the situation of each classification can also be seen, thus ensuring the reliability of the released software.

[0195] In summary, the present invention improves patch management and analysis through multi-level classification, supports a flexible version release mechanism, and provides a simplified branch merging process.

[0196] The classification of the present invention is essentially different from the sub-repository system of the existing repository. The classification management of the present invention can dynamically adjust the classification management content according to the software repository. Once a sub-repository is created, it is very difficult to flexibly change, and there is only the issue of retention or deletion.

[0197] Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

Claims

1. A multi-level classification management patch system, characterized in that: Includes classification management tree, software patch warehouse and classification patch warehouse; The classification management tree manages the information of each classification, each classification includes corresponding classification attributes, and the classification attributes refer to a collection of classification related information; the classification attributes include the following information: classification ID, patch classification description, patch classification identification; the patch classification description includes classification name, classification function description, classification content, parent class relationship description and child class relationship description; the patch classification identification refers to the identification of the classification attribute of the patch; The software patch warehouse is a warehouse that arranges software patches according to submission time; the classified patch warehouse is a warehouse that projects each patch in each software patch according to the patch's attributes onto the corresponding classification category of the classification management tree to generate classified patches, and arranges the classified patches according to classification category and submission time; The multi-level classification management patch system can perform operations such as creating, updating, deleting, querying and merging classifications, thereby realizing the updating, deleting, querying and merging of patches; The creation of categories in the category management tree includes the following steps: (1) The user or administrator adds the required categories to the category management tree according to the requirements for patch classification. The system applies for a matching category ID and defines the category name, category function description, and category content according to the requirements of the user or administrator. If the category ID cannot be applied for, the system displays "Failed to create the category". Otherwise, the system proceeds to the next step. (2) The system searches for parent categories one by one in the category management tree according to the category function description and category content of the newly added category. If more than two parent categories are found, it will be displayed that the category creation failed. Otherwise, it will proceed to the next step. (3) If a parent class is found, the classification is created as a subclass under the parent class. The parent class contains a subclass pointer, and the subclass contains a parent class pointer. (4) After the above classification branch relationships are divided, the classification patch warehouse is updated according to the content of the latest classification management tree.

2. A multi-level classification management patch system according to claim 1, characterized in that: To update the classification patch repository during the classification creation step, follow these steps: aUser initiates a command to update the classified patch repository; b. Abolish the previous classified patch warehouse; c. extracting software patches one by one from the software patch warehouse, splitting the software patches into classified patches according to the classification contents of each level of classification in the classification management tree, submitting the classified patches to the corresponding position of the classified patch warehouse, and assigning a classified patch ID to the classified patch, wherein the classified patch ID is the software patch ID + the classification ID; d shows that after the extraction is completed, the updated classification patch repository is in the update state.

3. A multi-level classification management patch system according to claim 1, characterized in that: To delete a category in the category management tree, follow these steps: (1) The user initiates a command to delete a category; (2) Search the category in the category management tree according to the category ID to be deleted. If the category ID to be deleted is not found, it will display that the category deletion failed. If not, proceed to the next step. (3) Delete the corresponding category in the category management tree, and delete the pointer address of the category in the category attributes of its parent category and child category; (4) Update the classification patch repository according to the latest content of the classification management tree.

4. A multi-level classification management patch system according to claim 3, characterized in that: The steps to update the category patch repository after deleting a category in the category management tree are as follows: a Extract classified patches from each branch of the classified patch warehouse; b Extract the corresponding classification ID from the classification patch ID of the extracted classification patch; c. Match the category ID with the category ID of the deleted category; dIf the match is consistent, the corresponding classification patch will be deleted from the classification patch warehouse.

5. A multi-level classification management patch system according to claim 1, characterized in that: The multi-level classification management patch system can also perform software patch rollback, the steps are as follows: User A initiates a rollback to a certain software patch; B matches the software patch ID in the software patch warehouse. If the software patch ID cannot be found, it will be displayed that the patch rollback fails. If the software patch ID is found, it will proceed to the next step. C. delete the software patch whose submission time is later than the matched software patch; D. Roll back the classified patch in the classified patch repository corresponding to the deleted software patch.

6. A multi-level classification management patch system according to claim 5, characterized in that: The multi-level classification management patch system can also perform classification patch rollback, the steps are as follows: User A initiates a rollback to a certain category patch; B matches the corresponding classified patch ID in the classified patch warehouse. If the classified patch ID cannot be found, it will display that the classified patch rollback failed. If it is found, it will go to the next step; C. Delete all the classified patches of the same category after the submission time of the classified patch corresponding to the classified patch ID from the classified patch repository; D matches the patch corresponding to the classified patch from the software patches in the software patch repository, and deletes the matched patch.

7. A multi-level classification management patch system according to claim 1, characterized in that: The multi-level classification management patch system can also perform classification, patch and classification patch query, the steps are as follows: (1) How to search for a category in the category management tree: User A initiates a command to search for a category; B matches the category ID in the category management tree file. If the category ID cannot be found, it will be displayed that the category query failed. If it is found, it will go to the next step; C finds the classification item and lists the classification related information; (2) How to query patches: User A initiates a query to a certain patch; B matches the software patch ID or name or author in the software patch repository. If the software patch ID or name or author is not found, the query fails. If the software patch is found, the query fails. C shows the content of the patch; (3) Method for querying classified patches: User A initiates a query to a certain category patch; B matches the classified patch ID in the classified patch warehouse. If the classified patch ID cannot be found, it will be displayed that the classified patch query failed. If the classified patch ID is found, it will proceed to the next step. C shows the content of the classification patch.

8. A multi-level classification management patch system according to claim 1, characterized in that: The multi-level classification management patch system can also perform classification merging, which includes classification patch merging and branch classification merging. The classification patch merging steps are as follows: (1) Arrange the classified patches in a row by time, where the classified patch ID = software patch ID + classification ID; (2) Compare the software patch IDs of adjacent classified patches, and merge the overlapping contents of patches with the same software patch ID into one software patch; (3) After the merge is completed, the classification patch ID is converted into a software patch ID, and a software patch repository is formed in the order of submission time.

9. A multi-level classification management patch system according to claim 8, characterized in that: The steps for merging the branch classifications are as follows: (1) Generate a classified patch repository by category for the two branches to be merged; (2) Take the merged branch as the baseline and add the different classification patches of the merged branch to the baseline branch; (3) Reassign the baseline repository software patch ID to the newly merged classification patch to generate a new classification patch ID; (4) Handling merge conflicts; (5) After the conflicts are resolved, the classified patches are resynthesized into software patches and a new software patch repository is generated.

Images