Code file adjustment method and electronic device

Abstract

The application discloses a code file adjustment method and electronic equipment, and relates to the technical field of software development and maintenance, and comprises the following steps: decomposing a code change block in a patch file to obtain a sub code change block; determining an anchor line of the sub code change block, matching the anchor line with a code line in a code file to be adjusted to obtain a code block to be adjusted, and adjusting the code block to be adjusted by using the sub code change block to obtain an adjusted code file. The application can solve the problem that the context drift phenomenon will cause the code file adjustment to fail and the code file needs to be manually adjusted by a developer. The application can more accurately match the corresponding code block to be adjusted in the code file by decomposing the code change block into multiple small, independent and flexibly positioned sub code change blocks. Even if the context drift phenomenon occurs in the code file, the sub code change block can be positioned in the code file by using the anchor line, and the code file can be successfully adjusted.

Description

Code file adjustment methods and electronic devices Technical Field

[0001] This invention relates to the field of software development and maintenance technology, specifically to a method for adjusting code files and an electronic device. Background Technology

[0002] In software development and maintenance, text files following specific formats are used to adjust code files. For example, they may be used to fix code in the code files, update functionality, or patch security vulnerabilities. These formatted text files are commonly called patch files, and they clearly describe the specific modifications made from one version of a file to another using structured text.

[0003] Context drift occurs in code files. Context drift means that after a patch file is created but before it is applied, other modifications are made to the code file, causing the line numbers and context lines recorded in the patch file to become out of sync with the current state of the code file. When a patch file created for a specific code version (version A) needs to be applied to a slightly different code version (version B), context drift results in the code in the code file not perfectly matching the context and deleted lines recorded in the patch file, leading to code file adjustment failure. This forces developers to perform costly and error-prone manual intervention, manually merging or regenerating the patch file. Summary of the Invention

[0004] In view of this, the present invention provides a code file adjustment method and an electronic device to solve the problem that context drift causes code file adjustment to fail, requiring developers to manually adjust the code file.

[0005] Firstly, this application provides a method for adjusting code files, the method comprising:

[0006] The code change blocks in the patch file are decomposed to obtain sub-code change blocks;

[0007] The anchor line for the sub-code change block is determined in the patch file, where the anchor line is used to determine the location of the sub-code change block;

[0008] Match the anchor line with the line of code in the file to be adjusted to obtain the target line of code corresponding to the anchor line in the file to be adjusted;

[0009] The code block to be adjusted is determined based on the target code line, and the sub-code change block is used to adjust the code block to obtain the adjusted code file.

[0010] Secondly, this application provides a code file adjustment device, the device comprising:

[0011] The decomposition module is used to decompose the code change blocks in the patch file to obtain sub-code change blocks;

[0012] The anchor line determination module is used to determine the anchor lines of sub-code change blocks in the patch file, where the anchor lines are used to determine the position of the sub-code change blocks;

[0013] The code matching module is used to match anchor lines with lines of code in the code file to be adjusted, and obtain the target line of code corresponding to the anchor line in the code file to be adjusted.

[0014] The file adjustment module is used to determine the code block to be adjusted in the code file based on the target code line, and to adjust the code block to be adjusted using the sub-code change block to obtain the adjusted code file.

[0015] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the code file adjustment method described in the first aspect or any corresponding embodiment.

[0016] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the code file adjustment method described in the first aspect or any corresponding embodiment.

[0017] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the code file adjustment method described in the first aspect or any corresponding embodiment thereof.

[0018] This application addresses the issue of code file adjustment failures due to context drift, which necessitates manual adjustments by developers. By decomposing code change blocks into sub-code change blocks within a patch file, this method achieves its goal. The method decomposes code change blocks into smaller, independent, and flexibly locatable sub-code change blocks, allowing for more accurate matching of the corresponding sub-code change blocks within the code file. Furthermore, defining anchor lines for each sub-code change block helps pinpoint the correct application location within the code file. Even with context drift, the method can locate sub-code change blocks and successfully adjust the code file. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 is a flowchart illustrating the code file adjustment method according to an embodiment of this application;

[0021] Figure 2 is a flowchart of the code change block decomposition algorithm according to an embodiment of this application;

[0022] Figure 3 is a flowchart of an adaptive search algorithm based on anchor row according to an embodiment of this application;

[0023] Figure 4 is a structural block diagram of a code file adjustment device according to an embodiment of this application;

[0024] Figure 5 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0026] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0027] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0028] The specific application environment architecture or specific hardware architecture on which the execution of the method depends, in conjunction with the code file, is described here.

[0029] This application relates to a method and system for applying differentiated patches to source code files, particularly suitable for version control systems, automated build systems, and CI (Continuous Integration) / CD (Continuous Deployment) pipelines. In modern, high-speed iterative software delivery models, automated processes are crucial for ensuring efficiency and quality. CI / CD pipelines heavily rely on the ability to automatically apply patches to integrate code fixes, feature updates, or security vulnerability repairs. However, patch application failure is a critical point of failure in such automated processes, capable of interrupting the entire release process and causing significant waste of time and resources.

[0030] Context drift is defined as a situation where, after a patch is created but before it is applied, other modifications are made to the target source code file, causing the line numbers and context lines recorded in the patch file to become out of sync with the current state of the code file. Common causes of context drift include code formatting, changes to comments and documentation, and merging unrelated features. Context drift can cause current automated tools to fail, disrupting CI / CD pipelines and forcing developers to perform costly and error-prone manual intervention to merge or regenerate patches manually. The fundamental flaw of traditional diff formats lies in their over-reliance on a global, absolute coordinate system (i.e., line numbers) and a fragile, precisely matched local context. This design paradigm is no longer suitable for the highly dynamic and collaborative requirements of modern software development.

[0031] In software development and maintenance, the standard practice for distributing code changes is to use text files that follow a specific format, commonly known as patch files. Patch files clearly describe the specific modifications made from one file version to another using structured text. The core components of a patch file include: a file header, code change blocks (Hunks), context lines, deleted lines, and added lines. For example, a file header starting with `-a / file.txt` and `+b / file.txt` refers to the original source file (version A) and the modified code file (version B), respectively. A Hunk is the basic unit of change in a patch file, representing a continuous code modification. It includes the line numbers before and after the modification, the line number itself, and the specific code changes. Each Hunk is led by a header line, including the starting line number in both the original and new files, and the total number of lines in each version. Context lines are lines in the Hunk that begin with a space, indicating that the line existed before and after the modification and remained unchanged. They are used to precisely locate the modification position in the source file. Deleted and added lines are prefixed with a minus sign (-) and a plus sign (+), respectively, clearly indicating the code content that needs to be deleted from or added to the original version.

[0032] The core algorithm of standard patching tools is rigidly designed and lacks flexibility. A typical process for applying a hunk is as follows: the tool reads the starting line number from the hunk header. The tool jumps to a specific line in the target source file. Starting from that line, the tool compares each line with the context lines and deleted lines defined in the hunk. For successful application, the corresponding code snippet in the original source file must match exactly everything in the hunk except for added lines (+ lines). If the match is perfect, the tool performs the deletion and addition operations. However, the rigid mechanism of traditional patching tools makes them very fragile in dynamic and collaborative development environments. If the code in the code file does not perfectly match the context and deleted lines recorded in the patch file when applying the patch, the code file adjustment will fail. Furthermore, when a patch created for a specific code version (version A) needs to be applied to a slightly different version (version B), patch application often fails due to context drift.

[0033] Based on the above, this application provides a code file adjustment method that introduces a hunk decomposition algorithm. This algorithm intelligently decomposes a single, large hunk in a standard patch format into multiple smaller, logically independent sub-hunks based on its internal code change patterns. Instead of relying on global line numbers for location, this application defines a set of stable anchor lines for each sub-hunk. These anchor lines are located by executing a localized, multi-stage adaptive search strategy within the code file, thus finding the correct application location for each sub-hunk. This method significantly improves the reliability and automation of the patch application process by decomposing a large, failure-prone matching task into multiple small, independent, and flexibly locatable micro-tasks. It overcomes the rigidity of traditional patching tools and enables robust, fault-tolerant application of differentiated patches even when significant context drift occurs in the source file.

[0034] According to an embodiment of this application, a code file adjustment method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] This embodiment provides a code file adjustment method. Figure 1 is a flowchart of the code file adjustment method according to an embodiment of this application. As shown in Figure 1, the process includes the following steps:

[0036] Step S101: Decompose the code change blocks in the patch file to obtain sub-code change blocks.

[0037] Specifically, this embodiment designs four core module execution code file adjustment methods, including: patch parser, hunk decomposition engine, adaptive search engine, and file reconstruction engine.

[0038] A patch parser is used to read standard patch files and parse their contents into independent code change block (Hunk) data structures. The Hunk decomposition engine is one of the core logics of this embodiment. It divides each parsed code change block into a series of sub-code change blocks (sub-Hunks). These sub-code change blocks are smaller in granularity, easier to locate, and logically independent of each other. A sub-code change block is defined as the smallest, continuous code change block within a Hunk (i.e., consecutive + lines and / or - lines). The boundaries of sub-code change blocks are defined by one or more context lines (lines starting with a single space).

[0039] The process by which the Hunk decomposition engine decomposes code change blocks in a patch file is as follows: The Hunk decomposition engine traverses each Hunk in the patch file. For each complete Hunk, by traversing its internal code lines, it identifies the boundary between the change lines and the context lines, thereby decomposing a large change block into multiple independent sub-Hunks.

[0040] Step S102: Determine the anchor line of the sub-code change block in the patch file, wherein the anchor line is used to determine the position of the sub-code change block.

[0041] Specifically, in addition to breaking down a code change block into multiple sub-code change blocks, the Hunk decomposition engine also associates anchor lines for each sub-code change block for location. Anchor lines are used to determine the location of the sub-code change block, and the selection of anchor lines is crucial to ensuring the robustness of locating sub-hunks; a good anchor should possess high uniqueness and stability.

[0042] In the patch file, determine the anchor lines for the sub-code change blocks. For example, use one or more context lines before the sub-code change block as the front anchor and one or more context lines after the sub-code change block as the back anchor. Both the front and back anchors are anchor lines.

[0043] Step S103: Match the anchor line with the code line in the code file to be adjusted to obtain the target code line corresponding to the anchor line in the code file to be adjusted.

[0044] Specifically, this embodiment locates these anchor lines by implementing a localized, multi-stage adaptive search strategy in the code file, thereby finding the correct application location for each sub-code change block in the code file.

[0045] This process performs a three-stage search sequentially for each sub-hunk: exact match, whitespace-insensitive match, and fuzzy match, with increasing tolerance for errors in each stage. In each stage, the anchor line is matched against lines of code in the file to be adjusted, determining whether the match result indicates the target line of code in the file to be adjusted. Only after a failure in the previous stage will the process proceed to the next stage with higher tolerance, until a match is found or the change is marked as failed. Sub-code change blocks that cannot be located with sufficient confidence in all search stages are marked as failed.

[0046] Step S104: Determine the code block to be adjusted in the code file to be adjusted based on the target code line, and adjust the code block to be adjusted using the sub-code change block to obtain the adjusted code file.

[0047] Specifically, the code blocks to be adjusted in the code file are determined based on the target code lines. For example, lines between target code lines are grouped into code blocks to be adjusted. A file refactoring engine maintains a copy of the code file in memory. Changes to successfully located sub-code change blocks are applied to this copy. For example, deletion and insertion operations of corresponding code lines in the sub-code change blocks are performed on the code blocks to be adjusted in this copy, and finally, the adjusted code file is generated.

[0048] The process of applying successfully located sub-code change block changes to the copy includes, for example: determining adjustment operations for lines of code in the code block to be adjusted based on the sub-code change block, where adjustment operations include insertion, deletion, and modification operations; and adjusting the lines of code in the code block to be adjusted based on the adjustment operations.

[0049] The code file adjustment method provided in this embodiment decomposes the code change blocks in the patch file into sub-code change blocks; determines the anchor lines of the sub-code change blocks; matches the anchor lines with the code lines in the code file to be adjusted to obtain the code block to be adjusted; and adjusts the code block to be adjusted using the sub-code change blocks to obtain the adjusted code file. This method, by decomposing the code change block into multiple small, independent, and flexibly locatable sub-code change blocks, can more accurately match the corresponding code block to be adjusted in the code file. Furthermore, by defining anchor lines for each sub-code change block, the code block to be adjusted is determined in the code file using the anchor lines, thus finding the correct application location for each sub-code change block. Even if context drift occurs in the code file, the sub-code change blocks can still be located in the code file, and the code file can be successfully adjusted. This solves the problem that context drift causes code file adjustment failures, requiring developers to manually adjust the code file.

[0050] As an optional embodiment, the code change blocks in the patch file are decomposed to obtain sub-code change blocks, including:

[0051] Get the lines of code contained in the patch file;

[0052] In the code line, determine the first code line and the second code line, wherein the first code line is adjacent to the second code line, the line type of the first code line is the first preset line type, and the line type of the second code line is the second preset line type;

[0053] The boundaries of the sub-code change block are determined based on the first and second lines of code;

[0054] The code change blocks in the patch file are decomposed according to the boundaries to obtain sub-code change blocks.

[0055] Specifically, in this embodiment, a sub-code change block is defined as the smallest, continuous code change block within a Hunk (i.e., consecutive + lines and / or - lines), whose boundaries are defined by one or more context lines (lines that start with a single space).

[0056] The Hunk decomposition engine uses the Hunk decomposition algorithm to break down code change blocks in patch files into sub-code change blocks. The Hunk decomposition algorithm process includes: obtaining the code lines contained in the patch file; traversing all code lines within the Hunk; determining the line type of each code line, such as: change line (+ or -), or a context line with a space prefix. The first preset line type is, for example, change line (+ or -). The second preset line type is, for example, a context line with a space prefix.

[0057] Find two adjacent lines of code in all lines of code, where one line of code has a first preset line type and the other line of code has a second preset line type. Select the line of code with the first preset line type as the first line of code and the other as the second line of code.

[0058] The boundaries of sub-code change blocks are determined based on the first and second lines of code. For example, the first and second lines can be used directly as the boundaries of the sub-code change block, and the area between these two boundaries is the sub-code change block. Alternatively, the boundaries of a sub-code change block can be identified when the line type changes from a change line (+ or -) to a context line with a space prefix, or vice versa. The code change blocks in the patch file are then decomposed based on these boundaries to obtain the sub-code change blocks. Additionally, the Hunk decomposition engine selects an associated anchor line for each sub-code change block consisting of consecutive change lines.

[0059] The above process is shown in Figure 2. Input a single code change block; traverse each line in the code change block; determine whether this line is a context line. If it is, group consecutive change lines. If not, identify the boundaries of the sub-code change block and identify the sub-code change block.

[0060] In this embodiment, a large, faulty hunk is decomposed into multiple small, independent, and flexibly locatable sub-hunks, thereby improving the success rate of matching sub-hunks in the code file. This avoids the risks associated with traditional hunk-based code file adjustments and enhances the accuracy and flexibility of processing patch code change blocks.

[0061] As an optional embodiment, the anchor line for the sub-code change block is determined in the patch file, including:

[0062] In the patch file, a first preset number of first context lines are identified that are adjacent to and precede the sub-code change block;

[0063] Determine a second preset number of second context lines that are adjacent to and follow the sub-code change block;

[0064] An anchor line is obtained based on the first context line and the second context line, wherein the anchor line is contained in the first context line or the second context line.

[0065] Specifically, the choice of anchor line is key to ensuring the robustness of the location sub-code change block. A good anchor should have high uniqueness and stability.

[0066] In the patch file, a first preset number of context lines adjacent to and preceding the sub-code change block are designated as first context lines. This first preset number can represent one or more lines and can be set according to actual needs. Similarly, a second preset number of context lines adjacent to and following the sub-code change block are designated as second context lines. This second preset number can also represent one or more lines and can be set according to actual needs.

[0067] Based on the first context line and the second context line, the anchor line is obtained. For example, one or more context lines immediately preceding the sub-code change block are selected as the front anchor line; one or more context lines immediately following the sub-code change block are selected as the back anchor line; both the front anchor line and the back anchor line are anchor lines, and the anchor line is contained in the first context line or the second context line.

[0068] The above process is shown in Figure 2: determine the preceding anchor line of the sub-code change block; determine the following anchor line of the sub-code change block; and output the list of sub-code change blocks.

[0069] In this embodiment, instead of relying on global line numbers for location, a set of stable "anchor lines" is defined for each sub-code change block. These anchor lines are located by executing a localized, multi-stage adaptive search strategy in the code file, thereby finding the correct application location for each sub-Hunk.

[0070] As an optional embodiment, the anchor line for the sub-code change block is determined in the patch file, including:

[0071] Get the repetition rate of elements in the code file to be adjusted;

[0072] Determine the first element contained in the first context line and the second element contained in the second context line;

[0073] Determine the first distinguishing factor of the first context row based on the first element and the repetition rate of the first element;

[0074] Determine the second distinguishing factor of the second context row based on the repetition rate of the second element.

[0075] In the first context line, the first context line with the largest first distinguishability is taken as the previous anchor point, where the previous anchor point is contained in the anchor line;

[0076] In the second context line, the second context line with the highest second distinguishability is taken as the subsequent anchor point, where the subsequent anchor point is contained within the anchor line.

[0077] Specifically, to further enhance adaptability, this embodiment employs an advanced anchor selection strategy that goes beyond blindly choosing adjacent lines. The Hunk decomposition engine analyzes the "information entropy" or uniqueness of candidate context lines. For example, a line containing only a single right curly brace "}" is a low-quality anchor because it is very common in the code. Conversely, a line containing specific function calls and parameters, such as "result = calculate_complex_value(param1,param2);", is a high-quality anchor because it has extremely low repetition rates in the file. Therefore, in a preferred embodiment of the invention, the Hunk decomposition engine includes a heuristic evaluation module for selecting the most distinctive lines from the available context as anchors.

[0078] The heuristic evaluation module determines the anchor line of the sub-code change block in the patch file by: obtaining the repetition rate of elements in the code file to be adjusted. For example, the repetition rate is the proportion of the number of times an element appears to the total number of elements in the code file to be adjusted. If the total number of elements in the code file to be adjusted is 10,000, the repetition rate of a single right curly brace "}" is 100 times; the repetition rate of the element "result = calculate_complex_value(param1, param2);" is 1 time; the repetition rate of the element "{" is 200 times; and the repetition rate of the element "result = param3;" is 0.2% when it appears 20 times.

[0079] Determine the first element contained in the first context line and the second element contained in the second context line. For example, the first element contained in the first context line is the right curly brace "}" and the element "result = calculate_complex_value(param1, param2);"; the second element contained in the second context line is the left curly brace "{" and the element "result = param3;".

[0080] The first distinguishing factor of the first context line is determined based on the first element and the repetition rate of the first element. For example, the minimum repetition rate among the repetition rates of the first element is used as the first distinguishing factor of the first context line. If the repetition rates include 1% and 0.01%, then the first distinguishing factor is 0.01%; or, the sum of the repetition rates of the first element is used as the first distinguishing factor of the first context line, and the first distinguishing factor is 1.01%.

[0081] The second discrimination of the second context line is determined based on the repetition rate of the second element. For example, the minimum repetition rate among the repetition rates of the second element is used as the second discrimination of the second context line. If the repetition rates include 2% and 0.2%, then the second discrimination is 0.2%; or, the sum of the repetition rates of the second elements is used as the second discrimination of the second context line, and the second discrimination is 2.2%.

[0082] In the first context line, the first context line with the highest first distinguishing value is used as the preceding anchor line. In the second context line, the second context line with the highest second distinguishing value is used as the following anchor line. Both the preceding and following anchor lines are anchor lines, and the anchor lines are contained within either the first or second context line.

[0083] In this embodiment, the distinguishability of the context line is determined by calculating the element repetition rate, and the line with high distinguishability is selected as the front / back anchor point to avoid low-quality anchor points, thereby improving the uniqueness and accuracy of the anchor point and enhancing the adaptive capability and reliability of the sub-code change block location.

[0084] As an optional embodiment, the anchor line is matched with the code line in the code file to be adjusted to obtain the target code line corresponding to the anchor line in the code file to be adjusted, including:

[0085] Obtain the target sub-code change block, the target pre-anchor point, and the target post-anchor point corresponding to the target sub-code change block from the patch file. The target sub-code change block is contained within the sub-code change block.

[0086] Compare the target's front anchor point and target's back anchor point with the lines of code in the code file, and determine whether the code file contains the target's front anchor point and target's back anchor point based on the comparison results;

[0087] If the code file contains a target pre-anchor point and a target post-anchor point, the target code line is obtained based on the code lines between the target pre-anchor point and the target post-anchor point.

[0088] Specifically, in this embodiment, for each sub-code change block, the search engine sequentially executes a multi-stage, increasingly tolerant search strategy, including: three stages of searching: exact matching, whitespace-insensitive matching, and fuzzy matching. Only after a previous stage fails will it enter the next stage with higher tolerance, until a match is found or it is ultimately marked as failed.

[0089] This embodiment performs the first stage of search for the sub-code change block, namely precise anchor matching. The search engine first attempts to perform a direct, character-by-character string search in the code file to find the complete text block composed of the preceding and following anchors. This is the fastest and most reliable matching method, and is suitable for situations where the code file has not been modified or has been modified irrelevantly.

[0090] The target sub-code change blocks are retrieved sequentially from the patch file. Each target sub-code change block represents the sub-code change block that needs to be matched. The preceding anchor point of the target sub-code change block is used as the preceding anchor point of the target, and the following anchor point is used as the following anchor point of the target.

[0091] The target's pre-anchor point and target's post-anchor point are compared with the lines of code in the code file. Based on the comparison results, it is determined whether the code file contains the target's pre-anchor point and target's post-anchor point.

[0092] If the code file contains a target pre-anchor point and a target post-anchor point, the target code line is obtained based on the code line between the target pre-anchor point and the target post-anchor point. For example, the code line between the target pre-anchor point and the target post-anchor point is taken as the target code line, and the target code line can be combined into the code block to be adjusted later.

[0093] The above process is shown in Figure 3. Input a single character code change block; Stage 1: Precise anchor point matching; Determine if a match is found. If a match is found, enable sub-code change block change; If no match is found, proceed to the matching of subsequent stages.

[0094] As an optional embodiment, the method further includes:

[0095] If the code file does not contain a target pre-anchor point or a target post-anchor point, adjust the code format of the code file to obtain the processed code file.

[0096] If the processed code file contains a target pre-anchor point and a target post-anchor point, obtain the target code line based on the code line between the target pre-anchor point and the target post-anchor point;

[0097] If the processed code file does not contain the target's pre-anchor point or target's post-anchor point, obtain a preset number of text windows in the processed code file based on the sliding window.

[0098] Obtain the similarity between the text window and the anchor line, and obtain the target code line based on the text windows with a similarity greater than a preset threshold.

[0099] Specifically, if the code file does not contain a target preceding anchor or target following anchor, and an exact anchor match fails, it indicates that code formatting may have occurred. A second phase of matching is then performed, with whitespace-insensitive matching. The engine standardizes the anchor line and the content of the code file, for example, by removing leading and trailing whitespace characters from each line and merging consecutive whitespace characters within a line into a single space. The search is then repeated. This phase effectively handles context drift caused purely by code style adjustments.

[0100] Adjust the code format of the code file, for example: remove leading and trailing whitespace characters from each line of the code file, and merge multiple consecutive whitespace characters within a line into a single space. The resulting code file will be processed.

[0101] If the processed code file contains a target pre-anchor point and a target post-anchor point, the target code line is obtained based on the code line between the target pre-anchor point and the target post-anchor point. For example, the code line between the target pre-anchor point and the target post-anchor point is taken as the target code line, and the target code line can be combined into the code block to be adjusted later.

[0102] If the processed code file does not contain either the target's preceding or following anchor point, the second-stage matching has failed. A third-stage matching process is then performed: a scoring similarity search (fuzzy matching). The system will employ a more advanced string similarity algorithm (e.g., Levenshtein distance or Ratcliff / Obershelp algorithm). The engine uses a sliding window within the code file to calculate the similarity score between the anchor string and each text window.

[0103] A sliding window is used in the code file to obtain a predetermined number of text windows in the processed code file. A string similarity algorithm (e.g., Levenshtein distance or Ratcliff / Obershelp algorithm) is used to obtain the similarity between the text windows and the anchor lines.

[0104] To prevent erroneous matches during the third-stage matching process (i.e., an anchor point unexpectedly matching another similar but unrelated piece of code in the file), a match is only accepted if the highest similarity score found exceeds a pre-configured confidence threshold. The confidence threshold is a preset threshold, such as 95%, 96%, or other percentages.

[0105] If there are text windows with a similarity greater than a preset threshold, the target code line is obtained based on the text windows with a similarity greater than the preset threshold. For example, all code lines in text windows with a similarity greater than the preset threshold are taken as the target code lines.

[0106] The above process is shown in Figure 3. Stage 2: Insensitive matching of whitespace characters; determine whether the match is successful. If the match is successful, apply the sub-code change block. If the match is not successful, proceed to Stage 3: Scoring similarity search (fuzzy matching); determine whether the highest similarity score is greater than the confidence threshold. If it is greater, apply the sub-code change block. If the highest similarity score is not greater than the confidence threshold, mark the sub-code change block as failed.

[0107] In this embodiment, a localized, multi-stage adaptive search strategy is implemented in the code file to match anchor lines with lines of code in the code file. Based on the matching results, the target line of code is determined, thereby finding the correct application location for each sub-Hunk. This significantly improves the reliability and automation of the sub-code change block application process, providing an important technical improvement for software maintenance and deployment systems.

[0108] As an optional embodiment, the method further includes:

[0109] Create a list of marked records in a preset storage area, where the list of marked records is used to record the matching results of sub-code change blocks;

[0110] If no text window with a similarity greater than the preset threshold exists, generate a matching failure flag corresponding to the target sub-code change block;

[0111] Write the match failure flags to the flag record list.

[0112] Specifically, a preset storage area is used, for example, memory. A real-time representation of the code file (e.g., a list of strings) is maintained in this preset storage area as a list of marker records. This list of marker records is used to record the matching results of sub-code change blocks. For example, whenever a sub-hunk is successfully located, the matching result of the sub-hunk is first recorded as a successful match in the marker record list, and then the deletion and insertion operations of the corresponding code lines for that sub-hunk are performed on the code file.

[0113] If no text window with a similarity greater than the preset threshold exists, it indicates that the third-stage matching also failed, confirming that the target sub-code change block has failed to match. A matching failure flag corresponding to the target sub-code change block is generated and written to the flag record list.

[0114] In this embodiment, a list of flag records is created to record the matching results of sub-code change blocks. When a match fails, a corresponding flag is generated and written, clearly tracing the matching status and providing a clear basis for subsequent processing, thereby improving the standardization and controllability of patch processing.

[0115] As an optional embodiment, the method further includes:

[0116] If a match failure flag exists in the flag record list, the adjustment of the code file to be adjusted is aborted.

[0117] Generate error messages, which are used to indicate that the code file adjustment failed.

[0118] Specifically, this embodiment employs a strict mode. If any sub-Hunk application fails, the entire patching operation is immediately aborted, and an error is reported to the user. This mode is suitable for scenarios requiring atomic operations. Therefore, if a matching failure flag exists in the flag record list, the adjustment of the code file to be adjusted is aborted. An error message is generated and used to characterize the failure of the code file adjustment.

[0119] As an optional embodiment, after adjusting the code block to be adjusted using sub-code change blocks to obtain the adjusted code file, the method further includes:

[0120] Based on the match failure flags in the flag record list, determine the sub-code change blocks that failed to match;

[0121] Based on the sub-code change blocks that failed to match, information about the problems to be solved is obtained.

[0122] Specifically, this embodiment employs a forgiving mode. In forgiving mode, the system applies all successfully located sub-hunks and generates two artifacts: a partially fixed source code file and a new patch file containing only all failed sub-hunks. This mode significantly reduces the manual workload for developers, eliminating the need to resolve a large and complex conflict from scratch, and requiring only the handling of a few sub-hunks that failed to match.

[0123] Based on the match failure flags in the flag record list, the sub-code change blocks that failed to match are identified. After all sub-hunts have been processed, the system writes the modified file model in memory to the output file and generates a report on all failed sub-hunts for developers' reference. For example, based on the failed sub-code change blocks, a report on all failed sub-hunts is generated, which contains information on unresolved issues, i.e., the several failed sub-hunts that need to be processed.

[0124] In this embodiment of the application, by introducing a tolerance mode, a small list of issues to be resolved is provided to the developers, making the final manual cleanup work faster and less prone to errors, and significantly improving development and maintenance efficiency.

[0125] As an optional embodiment, the specific process of step S102 "determining the anchor line of the sub-code change block in the patch file" may also include steps A1 to A8.

[0126] In this embodiment, the core of the anchor point row determination strategy is to expand the range of anchor point candidates, combine multi-dimensional weighted scoring to screen the optimal front / back anchor points, balance the physical proximity of the anchor point and the sub-Hunk and the distinctiveness of the anchor point itself. The selection logic of the front and back anchor points is the same, only the direction of the candidate range is different.

[0127] Step A1: Preset configurable parameters.

[0128] Specifically, core adjustable parameters are defined in advance, such as: the number of lines to expand the anchor line candidate range, the weight of scoring dimensions, the low-quality anchor filtering threshold, and the uniqueness determination threshold. For example, the number of lines to expand the anchor line candidate range is: by default, 5 lines before and 5 lines after the sub-hunk (adjustable between 3 and 8 lines). The weight of scoring dimensions is: by default, the distance dimension weight is 40%, the discrimination dimension weight is 40%, and the line type dimension weight is 20%. The low-quality anchor filtering threshold is: candidate lines of code with a total score below 40 are directly excluded. The uniqueness determination threshold is: if a line appears more than 5 times in the file, its uniqueness score is directly recorded as 0.

[0129] Step A2: Locate the physical boundary of the sub-Hunk.

[0130] Specifically, the patch file and code file are first parsed to determine the line number range of the current sub-Hunk in the patch file, that is, to determine the start and end line numbers of the sub-Hunk. At the same time, the total number of lines in the code file is recorded to avoid the subsequent candidate range from exceeding the beginning and end boundaries of the file.

[0131] Step A3: Construct the candidate set of front anchor points and the candidate set of back anchor points.

[0132] Specifically, first, a candidate set of front anchor points is constructed. Taking the starting line of the sub-Hunk as the reference, a preset number of extended lines (default 5 lines) are selected forward as the candidate range, and the candidate range must not be less than the first line of the file. Then, blank lines, pure comment lines, and lines containing only common symbols such as right curly braces and semicolons in the candidate range are removed. Finally, a list of candidate code lines for front anchor points is compiled, and the line number and content of each line are recorded.

[0133] Then, construct a candidate set for subsequent anchor points, using the end line of the sub-hunk as the baseline, and select a preset number of extended lines (default 5 lines) as the candidate range. The candidate range must not exceed the last line of the file. The filtering rules are the same as those for the candidate set for previous anchor points. Finally, compile a list of candidate code lines for subsequent anchor points and record the line number and content of each line.

[0134] Step A4: Calculate the three-dimensional scores of the candidate lines of code.

[0135] Specifically, for each row in the candidate lists of the front and rear anchor points, the distance score, the discrimination score, and the row type score are calculated respectively, and all scores are mapped to 0 to 100.

[0136] The distance score measures the physical proximity of a candidate code line to a sub-Hunk; the closer the sub-Hunk, the higher the score. For example, the candidate code line immediately adjacent to the sub-Hunk has the highest score, and the score decreases proportionally for each additional line of distance, with the farthest candidate code line receiving a score of 0.

[0137] The discrimination score is calculated by combining two dimensions: uniqueness and information entropy, each accounting for 50% of the weight. For uniqueness, the frequency of candidate code lines in the code file is counted; if the frequency exceeds a preset threshold of 5 times, a score of 0 is given, and the lower the frequency, the higher the score. For information entropy, candidate code lines are first broken down into tokens such as identifiers, keywords, and parameters, and then the Shannon entropy of the token distribution is calculated. The higher the Shannon entropy value, the higher the information content of the line, and the higher the score. Finally, the entropy value is mapped to a score from 0 to 100.

[0138] The line type score is assigned based on the structural characteristics of the line. Function / class definition lines score the highest (100 points), followed by variable / constant definition lines (80 points), ordinary business statement lines score 50 points, and lines containing only general symbols score 0 points.

[0139] Step A5: Calculate the weighted total score of the candidate code lines.

[0140] Specifically, according to a preset weight ratio, the distance score, discrimination score, and line type score of each line are weighted and summed to obtain the total score of the candidate code line. For example, if a line has a distance score of 80, a discrimination score of 60, and a line type score of 100, the total score is 80×40%+60×40%+100×20%=76 points.

[0141] Step A6: Filter low-quality candidate lines of code.

[0142] Specifically, candidate code lines with a total score below the preset threshold of 40 points are removed from the list, and only candidate code lines with a total score that meets the threshold are retained for the next step of screening.

[0143] Step A7: Select the optimal front / back anchor point.

[0144] Specifically, if the filtered candidate list is not empty, the line of code with the highest total score is selected as the final front or back anchor point. If multiple lines of code have the same total score, the line with the closest physical distance to the ion hunk is selected first. If the filtered candidate list is empty, the line of code immediately adjacent to the sub-hunk is selected as the anchor line, and this anchor line is marked as a low-quality anchor line for error handling in subsequent processes.

[0145] Step A8: Output the anchor point results.

[0146] Specifically, record the core information of the final selected front and back anchor points, including line number, line content, total score, and specific scores for each dimension; if it is necessary to improve fault tolerance, the second-highest total score suboptimal anchor point can be output as a backup anchor point.

[0147] In this embodiment, by expanding the candidate range and using multi-dimensional weighted scoring, the proximity and distinguishability of anchor points are balanced, and highly unique and stable anchor points are selected. Combined with a low-quality anchor point fault tolerance mechanism, this effectively addresses code format adjustments and context drift, thereby improving the robustness of anchor point positioning.

[0148] This embodiment also provides a code file adjustment device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0149] This embodiment provides a code file adjustment device, as shown in Figure 4, including:

[0150] The decomposition module 401 is used to decompose the code change blocks in the patch file to obtain sub-code change blocks;

[0151] Anchor line determination module 402 is used to determine the anchor line of the sub-code change block in the patch file, wherein the anchor line is used to determine the position of the sub-code change block;

[0152] The code matching module 403 is used to match the anchor line with the code line in the code file to be adjusted, so as to obtain the target code line corresponding to the anchor line in the code file to be adjusted;

[0153] The file adjustment module 404 is used to determine the code block to be adjusted in the code file to be adjusted based on the target code line, and to adjust the code block to be adjusted using the sub-code change block to obtain the adjusted code file.

[0154] As an optional embodiment, the decomposition module 401 includes:

[0155] The first acquisition unit is used to acquire the lines of code contained in the patch file;

[0156] The first determining unit is used to determine a first code line and a second code line in the code line, wherein the first code line and the second code line are adjacent, the line type of the first code line is a first preset line type, and the line type of the second code line is a second preset line type;

[0157] The second determining unit is used to determine the boundary of the sub-code change block based on the first code line and the second code line;

[0158] Decomposition units are used to decompose code change blocks in a patch file according to boundaries to obtain sub-code change blocks.

[0159] As an optional embodiment, the anchor line determination module 402 includes:

[0160] The third determining unit is used to determine, in the patch file, a first preset number of first context lines that are adjacent to and precede the sub-code change block;

[0161] The fourth determining unit is used to determine a second preset number of second context lines that are adjacent to and follow the sub-code change block;

[0162] The first obtaining unit is used to obtain the anchor line based on the first context line and the second context line, wherein the anchor line is contained in the first context line or the second context line.

[0163] As an optional embodiment, the anchor line determination module 402 includes:

[0164] The second acquisition unit is used to acquire the repetition rate of elements in the code file to be adjusted;

[0165] The fifth determining unit is used to determine the first element contained in the first context row and the second element contained in the second context row;

[0166] The sixth determining unit is used to determine the first distinguishability of the first context row based on the first element and the repetition rate of the first element;

[0167] The seventh determining unit is used to determine the second discrimination of the second context line based on the repetition rate of the second element and the second element.

[0168] The first setting unit is used to select the first context line with the largest first distinguishability as the previous anchor point in the first context line, wherein the previous anchor point is contained in the anchor line;

[0169] The second setting unit is used to select the second context line with the highest second distinguishability as the subsequent anchor point in the second context line, wherein the subsequent anchor point is contained in the anchor line.

[0170] As an optional embodiment, the code matching module 403 includes:

[0171] The third acquisition unit is used to acquire the target sub-code change block, the target front anchor point and the target back anchor point corresponding to the target sub-code change block in the patch file, wherein the target sub-code change block is contained in the sub-code change block;

[0172] The judgment unit is used to compare the target's front anchor point and target's back anchor point with the code lines in the code file, and determine whether the code file contains the target's front anchor point and target's back anchor point based on the comparison result;

[0173] The second obtaining unit is used to obtain the target code line based on the code line between the target's front anchor point and target's back anchor point when the code file contains the target's front anchor point and target's back anchor point.

[0174] As an optional embodiment, the code matching module 403 includes:

[0175] The adjustment unit is used to adjust the code format of the code file when the code file does not contain a target pre-anchor point or a target post-anchor point, so as to obtain the processed code file.

[0176] The third obtaining unit is used to obtain the target code line based on the code line between the target pre-anchor point and the target post-anchor point if the processed code file contains a target pre-anchor point and a target post-anchor point;

[0177] The fourth acquisition unit is used to acquire a preset number of text windows in the processed code file according to the sliding window if the processed code file does not contain the target pre-anchor point or the target post-anchor point.

[0178] The fourth unit is used to obtain the similarity between the text window and the anchor line, and to obtain the target code line based on the text window whose similarity is greater than a preset threshold.

[0179] As an optional embodiment, the device further includes:

[0180] A module is created to create a list of marked records in a preset storage area. The list of marked records is used to record the matching results of sub-code change blocks.

[0181] The first generation module is used to generate a matching failure flag corresponding to the target sub-code change block if there is no text window with a similarity greater than a preset threshold.

[0182] The write module is used to write the match failure flags to the flag record list.

[0183] As an optional embodiment, the device further includes:

[0184] The abort module is used to abort the adjustment of the code file to be adjusted if there is a failed match flag in the flag record list.

[0185] The second generation module is used to generate error messages, which are used to indicate that the adjustment of the code file failed.

[0186] As an optional embodiment, the device further includes:

[0187] The determination module is used to determine the sub-code change blocks that fail to match based on the match failure flags in the flag record list;

[0188] The module is used to obtain information about the problems to be solved based on the sub-code change blocks that failed to match.

[0189] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0190] In this embodiment, the code file adjustment device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0191] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0192] Referring specifically to Figure 5, a schematic diagram of a suitable electronic device for implementing embodiments of the present invention is shown below. The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0193] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 shows an electronic device with various devices, it should be understood that it is not required to implement or have all the devices shown, and more or fewer devices may be implemented or have alternatively.

[0194] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a memory 508, or installed from a ROM 502. When the computer program is executed by the processor 501, it performs the functions defined in the code file adjustment method of the embodiments of the present invention.

[0195] The electronic device shown in Figure 5 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0196] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the code file adjustment method shown in the above embodiments is implemented.

[0197] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0198] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for adjusting code files, characterized in that, The method includes: decomposing code change blocks in a patch file to obtain sub-code change blocks; determining anchor lines for the sub-code change blocks in the patch file, wherein the anchor lines are used to determine the position of the sub-code change blocks; determining the anchor lines for the sub-code change blocks in the patch file includes: determining a first preset number of first context lines adjacent to and preceding the sub-code change blocks in the patch file; determining a second preset number of second context lines adjacent to and following the sub-code change blocks; obtaining the anchor lines based on the first and second context lines, wherein the anchor lines are contained within the first or second context lines; determining the anchor lines for the sub-code change blocks in the patch file includes: obtaining the repetition rate of elements in the code file to be adjusted; determining the first upper and lower... The first context line contains a first element, and the second context line contains a second element; based on the repetition rate of the first element and the second element, a first distinguishability of the first context line is determined; based on the repetition rate of the second element and the second element, a second distinguishability of the second context line is determined; in the first context line, the first context line with the largest first distinguishability is taken as the front anchor point, wherein the front anchor point is contained in the anchor line; in the second context line, the second context line with the largest second distinguishability is taken as the back anchor point, wherein the back anchor point is contained in the anchor line; the anchor line is matched with the code line in the code file to be adjusted to obtain the target code line corresponding to the anchor line in the code file to be adjusted; based on the target code line, the code block to be adjusted in the code file to be adjusted is determined, and the code block to be adjusted is adjusted using the sub-code change block to obtain the adjusted code file.

2. The method according to claim 1, characterized in that, The step of decomposing the code change block in the patch file to obtain sub-code change blocks includes: obtaining the code lines contained in the patch file; determining a first code line and a second code line in the code lines, wherein the first code line and the second code line are adjacent, the line type of the first code line is a first preset line type, and the line type of the second code line is a second preset line type; determining the boundary of the sub-code change block based on the first code line and the second code line; and decomposing the code change block in the patch file based on the boundary to obtain the sub-code change block.

3. The method according to claim 1, characterized in that, The step of matching the anchor line with the code line in the code file to be adjusted to obtain the target code line corresponding to the anchor line in the code file to be adjusted includes: obtaining the target sub-code change block, the target pre-anchor point, and the target post-anchor point corresponding to the target sub-code change block in the patch file, wherein the target sub-code change block is contained within the sub-code change block; comparing the target pre-anchor point and the target post-anchor point with the code line in the code file to be adjusted, and determining whether the code file to be adjusted contains the target pre-anchor point and the target post-anchor point based on the comparison result; if the code file to be adjusted contains the target pre-anchor point and the target post-anchor point, obtaining the target code line based on the code line between the target pre-anchor point and the target post-anchor point.

4. The method according to claim 3, characterized in that, The method further includes: if the target pre-anchor point or the target post-anchor point is not contained in the code file to be adjusted, adjusting the code format of the code file to be adjusted to obtain a processed code file to be adjusted; if the processed code file to be adjusted contains the target pre-anchor point and the target post-anchor point, obtaining the target code line based on the code line between the target pre-anchor point and the target post-anchor point; if the processed code file to be adjusted does not contain the target pre-anchor point or the target post-anchor point, obtaining a preset number of text windows in the processed code file to be adjusted according to a sliding window; obtaining the similarity between the text window and the anchor line, and obtaining the target code line based on the text window with a similarity greater than a preset threshold.

5. The method according to claim 3, characterized in that, The method further includes: creating a tag record list in a preset storage area, wherein the tag record list is used to record the matching results of the sub-code change block; if there is no text window with a similarity greater than a preset threshold, generating a matching failure tag corresponding to the target sub-code change block; and writing the matching failure tag into the tag record list.

6. The method according to claim 5, characterized in that, The method further includes: if the matching failure flag exists in the flag record list, suspending the adjustment of the code file to be adjusted; generating error information, wherein the error information is used to indicate that the adjustment of the code file has failed.

7. The method according to claim 5, characterized in that, After adjusting the code block to be adjusted using the sub-code change block to obtain the adjusted code file, the method further includes: determining the sub-code change block that failed to match based on the matching failure flag in the flag record list; and obtaining the problem information to be solved based on the sub-code change block that failed to match.

8. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the code file adjustment method of any one of claims 1 to 7 by executing the computer instructions.

Images