Method and apparatus for large code base fork maintenance

Abstract

The embodiment of the present disclosure provides a large code base fork maintenance method and device, the method comprises the following steps: creating a companion file with the same name as each upstream original file and with a preset suffix in the folder of the upstream original file; writing custom function code into each companion file, and adding a side effect import statement in each upstream original file. The large code base fork maintenance method and device provided by the embodiment of the present disclosure can minimize the amount of merge conflicts by creating a companion file with the same name as each upstream original file and with a preset suffix in the folder of the upstream original file, and writing custom function code into each companion file, so that the invasive modification of the upstream original file is compressed to the minimum, the workload of conflict resolution is reduced, and the cost of large code base fork maintenance is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method and apparatus for maintaining a large codebase fork. Background Technology

[0002] After the upstream code repository is forked, the upstream code can be modified directly on the downstream branch. When the upstream releases a new version, the upstream changes are merged into the downstream branch using a merge command. Developers need to resolve conflicts that arise during the merge process one by one, or they can use the system platform's auxiliary functions to record conflict solutions to reduce repetitive work.

[0003] Every direct modification to an upstream file is a potential merge conflict point. When custom modifications are scattered across many upstream files, each upstream synchronization may generate numerous merge conflicts, making resolution extremely costly. Summary of the Invention

[0004] This disclosure provides a method and apparatus for maintaining a large codebase fork, which can solve the technical problem of high cost of resolving merge conflicts during the maintenance of a large codebase fork.

[0005] In a first aspect, embodiments of this disclosure provide a method for maintaining a large codebase fork, including: Create a companion file in the folder containing the upstream original files, with the same name as each upstream original file and the default suffix; Write the custom functionality code into each companion file and add a side effect import statement to each upstream original file.

[0006] In some embodiments, the method further includes: When the upstream source file must be modified, use level 3 tags to comment out the modified code; The three levels of tags include single-line tags, single-line tags with descriptions, and code block tags.

[0007] In some embodiments, all companion files have the same default file extension.

[0008] In some embodiments, the method further includes: Add an identifier with a target prefix to the custom function code, which is different from the identifier in the upstream original file.

[0009] In some embodiments, the identifiers include: inter-process communication channel identifier, remote procedure call agent identifier, dependency injection service identifier, and extended contribution point identifier.

[0010] In some embodiments, the modified upstream original file retains the upstream copyright header; the accompanying file uses the downstream copyright header.

[0011] In some embodiments, the directory structure of the customized function code is the same as the directory structure of the upstream original file.

[0012] Secondly, embodiments of this disclosure provide a large-scale codebase fork maintenance apparatus, the apparatus comprising: Create a module to create a companion file in the folder containing the upstream original files. The companion file has the same name as each upstream original file and the same suffix as the preset suffix. The write module is used to write custom functionality code into each companion file and add side-effect import statements to each upstream original file.

[0013] Thirdly, embodiments of this disclosure provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0014] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0015] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0016] The large codebase fork maintenance method and apparatus provided in this disclosure minimizes the number of merging conflicts and reduces intrusive modifications to upstream original files by creating companion files with the same name and preset suffixes in the folder of the upstream original files and writing customized function code into each companion file. This reduces the workload of conflict resolution and lowers the cost of large codebase fork maintenance. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below.

[0018] Figure 1 A flowchart illustrating a method for maintaining a large codebase fork, provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of a process for determining the creation of companion files, provided in an embodiment of the present disclosure. Figure 3 A schematic diagram of a cascading structure of companion files provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram illustrating cross-layer identifier tracing provided in an embodiment of the present disclosure; Figure 5 A schematic diagram of the directory structure of a customized module provided in an embodiment of this disclosure; Figure 6 A schematic diagram of the directory structure of a cocosAssets module provided in an embodiment of this disclosure; Figure 7 This is a schematic diagram of an upstream and downstream file merging process provided in an embodiment of the present disclosure; Figure 8 A schematic diagram of a large codebase fork maintenance device provided in this embodiment of the disclosure; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0019] The embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions of the embodiments of this disclosure.

[0020] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this disclosure mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element are connected through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term, for example, “A and / or B” or “A, B” indicates implementation as “A,” or implementation as “B,” or implementation as “A and B.”

[0021] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0022] First, the technical terms used in this disclosure will be introduced and explained: Upstream codebase: The original open-source project codebase that has been forked. For example, VS Code.

[0023] Downstream codebase: A forked project that is customized based on the upstream codebase. For example, Pink IDE.

[0024] Companion File: A custom file located in the same directory and with the same name as the upstream original file, but using a specific suffix (e.g., .pink.ts), carrying all the newly added functional code downstream. The companion file coexists with the upstream original file in directory location and lifecycle, but is completely independent in terms of file content and copyright ownership.

[0025] Intrusive modification: The act of directly modifying the content of the original upstream file. Each modification will cause a merge conflict during subsequent upstream synchronization.

[0026] Merge conflict: Text conflicts arising from upstream code updates and downstream modifications in the same area of ​​the same file require manual resolution.

[0027] Side-effect import: Only executes the module's side effects (e.g., registering services, contribution points) without importing any bound import statements.

[0028] Dependency Injection (DI): A service instantiation and management pattern in the VS Code architecture.

[0029] Inter-Process Communication (IPC): The communication mechanism between the Electron main process and the rendering process.

[0030] Remote Procedure Call (RPC): An abstraction for method calls across process boundaries.

[0031] Marking annotations: Special annotation markers (e.g., @pink, @pink-start, @pink-end) are used to mark custom modification areas in the upstream original file.

[0032] Contribution Point: A mechanism in the VS Code architecture used for modular registration of feature extensions.

[0033] Registration-based architecture: The architecture pattern adopted by VS Code uses registration functions such as registerSingleton() to centrally register all service implementations at the startup entry point.

[0034] In some embodiments, Git branch management and a rebase workflow are used to fork and maintain large codebases. Developers fork the upstream repository and then directly modify the upstream code on the downstream branch. When the upstream releases a new version, the changes are merged into the downstream branch using `git rebase` or `git merge`. Developers need to resolve conflicts that arise during the merge process one by one. Some teams use `git rerere` (reuse recorded resolution) to record conflict resolutions to reduce redundant work.

[0035] However, the above solution has the following drawbacks: 1. The number of merge conflicts is positively correlated with the number of intrusive modifications: Every direct modification to an upstream file is a potential merge conflict point. When custom modifications are scattered across hundreds of upstream files, each upstream synchronization may generate hundreds of conflicts, making resolution extremely costly.

[0036] 2. Invisible modification intent: Git diff only displays text changes and cannot distinguish whether a line of code represents a custom modification or a refactoring of the upstream file itself. Developers lack semantic-level context when resolving conflicts.

[0037] 3. Inability to isolate custom code: Custom code is scattered in various locations in upstream files, making it impossible to extract, analyze, or audit all custom modifications in batches through simple file operations.

[0038] 4. Not suitable for large-scale customization: When the downstream needs to add functional modules with hundreds of files, these new files are not structurally distinguished from the upstream files at the version control level.

[0039] In view of at least one of the above-mentioned technical problems or areas that need improvement in the related technologies, this disclosure provides a method and apparatus for maintaining a large codebase fork. By creating companion files with the same name as each upstream original file and a preset suffix in the folder of the upstream original file, and writing customized function code into each companion file, the amount of merging conflicts is minimized, the intrusive modifications to the upstream original files are reduced to a minimum, the workload of conflict resolution is reduced, and the cost of maintaining a large codebase fork is lowered.

[0040] The following description of several exemplary embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0041] Figure 1This is a flowchart illustrating a method for maintaining a large codebase fork, as provided in an embodiment of this disclosure. Figure 1 As shown, the method includes: Step 101: Create a companion file in the folder containing the upstream original files, with the same name as each upstream original file and the same default extension.

[0042] Specifically, when large open-source IDEs (e.g., VS Code, with approximately 1 million lines of TypeScript code) are forked to build vertical domain IDEs (e.g., game development IDEs), a large number of custom feature modules need to be added. The traditional method of directly modifying upstream files results in numerous merge conflicts every time upstream is synchronized, and maintenance costs increase linearly or even superlinearly with the scale of customization.

[0043] Figure 2 This is a schematic diagram of a process for determining the creation of companion files provided in an embodiment of this disclosure, such as... Figure 2 As shown in this embodiment, it is first necessary to determine whether a customized function needs to be added to the upstream entry / registration point. If it is determined that a customized function needs to be added to the upstream entry / registration point, it is determined whether a companion file (also known as an accompanying file) already exists at the entry / registration point. If a companion file already exists at the entry / registration point, the registration code can be extracted from the existing companion file. If a companion file does not exist at the entry / registration point, a new companion file can be created.

[0044] In this embodiment of the disclosure, a companion file with the same name as each upstream original file and a preset suffix is ​​created in the folder of the upstream original files.

[0045] For example, VS Code's module loading mechanism—the entry file is loaded when the application starts, and the `registerSingleton()` call in the entry file determines which services will be instantiated. New services must be registered during the entry file loading process; otherwise, the DI container cannot discover them. In this codebase, downstream custom code involves 175 upstream source files, requiring the creation of 175 companion files (83 for the platform layer, 90 for the workbench layer, and 2 others). Companion files and upstream source files follow a strict correspondence, as shown in Table 1: Table 1. Correspondence between accompanying files and upstream original files

[0046] Step 102: Write the custom function code into each companion file and add a side effect import statement to each upstream original file.

[0047] Specifically, after creating the companion files, the custom functionality code is written into each companion file. Side effect import statements are also added to each upstream source file.

[0048] In some embodiments, the content of the companion file can be service registration and contribution point declarations, leveraging VS Code's registration-based architecture. Taking the entry companion file as an example, its internal structure contains two areas: The first area is the contribution registration area, which loads the contribution registration files of each functional module through side-effect import statements. Each import statement points to a module file with the .pink.js suffix. When this module is loaded, it automatically executes the contribution registration logic (such as registering menu items, commands, view containers, etc.), and the caller does not need to explicitly call any functions.

[0049] The second area is the service singleton registration area, which binds the custom service interface and implementation class to the VS Code DI container through the registerSingleton() call. Each registration call specifies the service interface identifier (e.g., IPinkNetworkService), the implementation class (e.g., PinkNetworkService), and the instantiation strategy (e.g., delayed instantiationInstantiationType.Delayed).

[0050] The only change to the original entry file, workbench.desktop.main.ts, is the addition of a side-effect import statement at the end of the file (import '. / workbench.desktop.main.pink.js'; / / @pink). This statement automatically triggers the loading and execution of the companion file when the ES module loader processes the entry file, thereby activating all the aforementioned registration logic.

[0051] For example, in a VS Code repository, downstream custom code involves 175 upstream source files, requiring the creation of 175 companion files with the .pink.ts extension (83 for the platform layer, 90 for the workbench layer, and 2 for others). The intrusive modifications to the upstream files are limited to a few import statements and @pink annotation changes. This means that during upstream synchronization, the 175 custom files will have zero conflicts (it's impossible for the upstream to create a .pink.ts file with the same name); conflicts will only occur in the few marked upstream files.

[0052] All downstream custom code uses the .pink.ts suffix. The key design features of the .pink.ts suffix include four aspects. First, file system-level isolation—via find . -name " The `.pink.ts` extension can enumerate all custom files without needing to check their content file by file. Second, there are zero conflicts during upstream synchronization. The upstream will not create files with the `.pink.ts` extension (because `.pink` is a downstream-specific identifier), so these files will not conflict with the upstream during `git merge` / `git rebase`. Third, build tool compatibility is ensured. `.pink.ts` files remain valid TypeScript files, and all standard toolchains (TypeScript compilers, ESLint, testing frameworks) can handle them without any configuration. Fourth, code review assistance is provided. In pull requests, reviewers can quickly distinguish between custom code changes and upstream synchronization changes.

[0053] In some embodiments, when the customized functionality involves a multi-layered module system (such as extended API registration in the extended host process, RPC agent registration in the extended host, IPC channel registration in the main process, etc.), the companion files can form a cascaded structure. Figure 3 This is a schematic diagram of a cascading structure of accompanying files provided in an embodiment of this disclosure, such as... Figure 3 As shown, taking extended host contribution registration as an example, each companion file is responsible for the registration logic of its layer, forming a tree structure. Upper-level companion files only need to import lower-level companion files, and the actual registration operation is completed within the lower-level companion files. This cascading structure ensures that each companion file has a single responsibility and is self-contained. When adding new features, only a new companion file needs to be created at the appropriate level, and an import line needs to be added to the upper level. This avoids the coupling and bloat caused by concentrating all registration logic in a single file.

[0054] The large-scale codebase fork maintenance method disclosed in this embodiment utilizes the ES module side-effect import mechanism of JavaScript / TypeScript and the registration architecture of the host framework (VS Code) to physically separate downstream custom code from upstream files into independent companion files. Simultaneously, it manages a small number of unavoidable intrusive modifications through structured tagging and comments, allowing the size of the custom code to grow freely while maintaining a constant level of intrusion into upstream files. This reduces the workload of conflict resolution and lowers the cost of forking and maintaining large-scale codebases.

[0055] In some embodiments, the method further includes: When the upstream source file must be modified, use level 3 tags to comment out the modified code; The three levels of tags include single-line tags, single-line tags with descriptions, and code block tags. Specifically, while the companion file pattern can cover most customized scenarios (service registration, contribution point declaration, adding modules), some modifications inevitably require direct modification of upstream files. For example, adding fields to existing upstream interfaces, inserting logical branches into existing upstream class methods, or modifying the signatures of upstream functions. These intrusive modifications, scattered across upstream files, are difficult to locate and manage during upstream synchronization.

[0056] In this embodiment of the disclosure, when the upstream original file must be modified, a three-level tag is used to comment out the modified code; wherein, the three-level tag includes a single-line tag, a single-line tag with explanation, and a code block tag. For example, the three-level tags are shown in Table 2: Table 2. Level 3 Markings

[0057] The three-level tagging design follows the principle of minimum annotation: single-line modifications can use the end-of-line comment / / @pink, without the need for additional start and end tags; multi-line modification blocks use paired tags @pink-start / @pink-end to clearly define the boundaries of customized modifications; when the reason for modification is not obvious, explanatory text is added after the tag to provide a basis for decision-making for those resolving merging conflicts.

[0058] For example, Scenario A: Side effect import (most common): Add an import statement to the end of the original file and append the / / @pink suffix. This is the standard way to access companion files and accounts for the vast majority of all intrusive modifications.

[0059] For example, Scenario B: Interface extension (adding fields): When adding fields to an existing upstream interface definition, append / / @pink or / to the end of each new field line. @pink field description / Note. Reviewers can quickly identify which fields are original to the upstream and which are newly added downstream.

[0060] For example, in scenario C: a multi-line logic modification block, when inserting multi-line custom logic into the upstream method body, the entire modification block is wrapped with the ` / / @pink-start` and ` / / @pink-end` tags. The merge conflict resolver can understand from these tags that the entire block was added downstream and needs to be retained or re-adapted.

[0061] In this embodiment of the disclosure, the uniform format of the annotations allows all intrusive modifications to be located through a simple text search, such as `grep -rn "@pink" --include="`. .ts" --exclude=" The .pink.ts file can enumerate all intrusive modifications in upstream files within seconds. (Excludes...) The .pink.ts file ensures that only tags in upstream files are retrieved. The retrieval results can be directly used for impact assessment before upstream synchronization and integrity verification after synchronization.

[0062] In the embodiments provided in this disclosure, when the companion file mode cannot meet the requirements, direct modification of the upstream file is allowed, but each modification must be marked with a tag annotation. The tagging mechanism makes all intrusive modifications searchable by machines and auditable by humans, and also provides structured anchors for automated merging tools, further improving the efficiency of merging conflict resolution.

[0063] In some embodiments, all companion files have the same default file extension.

[0064] In the embodiments provided in this disclosure, all companion files have the same default suffix. For example, all custom code files uniformly use the .pink.ts suffix, which naturally separates the custom code from the upstream code at the file system level, and can be achieved through simple filename pattern matching. The .pink.ts file enables batch location, statistics, and management, further improving the efficiency of resolving merge conflicts.

[0065] In some embodiments, the method further includes: Add an identifier with a target prefix to the custom function code, which is different from the identifier in the upstream original file.

[0066] Specifically, Electron-based IDEs involve multiple processes (main process, rendering process, extended host process, and external engine process). Inter-process communication requires identifiers such as IPC Channel ID and RPC Proxy ID for addressing. New communication channels downstream must be completely isolated from existing channels upstream in namespace; otherwise, identifier conflicts may lead to incorrect message routing.

[0067] In this embodiment of the disclosure, a clear naming prefix is ​​defined for each layer to ensure that the customized identifier does not conflict with the upstream identifier, and the corresponding service layer and affiliation can be quickly traced from an identifier.

[0068] In some embodiments, the identifiers include: inter-process communication channel identifier, remote procedure call agent identifier, dependency injection service identifier, and extended contribution point identifier.

[0069] In this embodiment of the disclosure, the identifiers with target prefixes added to the customized function code include inter-process communication channel identifiers (IPC Channel ID), remote procedure call proxy identifiers (RPC Proxy ID), dependency injection service identifiers (DI Service ID), and extended contribution point identifiers.

[0070] Figure 4 This is a schematic diagram of cross-layer identifier tracing provided in an embodiment of the present disclosure, such as... Figure 4 As shown, by embedding the pink or cocos prefix in each layer identifier, three goals are ensured: custom identifiers will not conflict with upstream VS Code identifiers (upstream does not use pink / cocos prefixes); developers can determine the identifier's affiliation (upstream vs. custom) and level (IPC vs. RPC vs. DI vs. Extension Point) simply by looking at it; and when tracing across layers, prefix association allows tracing from Extension Point all the way to IPC Channel.

[0071] In this embodiment of the disclosure, it is ensured that the customized identifier and the upstream identifier do not conflict in the namespace, and the cross-layer identifier relationship is clear and traceable, which further improves the efficiency of resolving merge conflicts.

[0072] In some embodiments, the modified upstream original file retains the upstream copyright header; the accompanying file uses the downstream copyright header.

[0073] Specifically, the .pink.ts file uses the downstream copyright header, and modified upstream files retain the upstream copyright header, which is automatically verified by the build tool. This makes the intellectual property ownership of each file clear at a glance.

[0074] In this embodiment, the first copyright header identifies the downstream original code, and the second copyright header identifies the upstream code (even if it includes modifications marked with @pink). File-level copyright ownership is immediately clear, reducing the risk of intellectual property disputes.

[0075] In some embodiments, the directory structure of the customized function code is the same as the directory structure of the upstream original file.

[0076] Specifically, custom modules involve multiple process boundaries (service implementations in the main process, UI interactions in the rendering process, and shared interface definitions between the two), requiring proper directory organization. If a custom module adopts a directory structure completely different from the upstream, developers will need to frequently switch mental models when switching between upstream and custom code, increasing their cognitive burden.

[0077] Figure 5This is a schematic diagram of the directory structure of a customized module provided in an embodiment of this disclosure, such as... Figure 5 As shown in this embodiment, the directory organization of the custom module strictly follows the hierarchical pattern of the upstream VS Code.

[0078] For example, Figure 6 This is a schematic diagram of the directory structure of a cocosAssets module provided in an embodiment of this disclosure, as shown below. Figure 6 As shown, the complete directory structure of the cocosAssets module is an example. This isomorphic reuse means that: developers familiar with the VS Code architecture do not need to learn additional directory conventions; interface files under common / can be referenced by both the main process and the rendering process, avoiding duplication of type definitions; layering by process boundaries naturally matches Electron's multi-process architecture, and the file location implies its runtime environment.

[0079] In this embodiment, adding a new module only requires creating a .pink.ts file and appending registration code to the existing companion file, without needing to touch the upstream files. The integration process fully follows the standard service registration model of VS Code, eliminating the need for developers to learn additional frameworks or tools, further improving maintenance efficiency.

[0080] In some embodiments, the upstream (VS Code) releases a new version monthly, and the downstream needs to synchronize regularly to obtain security fixes and new features. During synchronization, changes from the upstream need to be merged into the codebase containing downstream custom modifications. This is the most costly and risky operation in fork maintenance; improper resolution of merge conflicts can lead to feature rollbacks or runtime crashes.

[0081] Figure 7 This is a schematic diagram of an upstream and downstream file merging process provided in an embodiment of the present disclosure, such as... Figure 7 As shown, when the upstream releases a new version and the downstream needs to update synchronously, the companion file mode significantly simplifies the merging process.

[0082] For example, when an upstream file is reconstructed, all the custom modifications scattered throughout the related technologies will conflict; in this embodiment, only one import line needs to be processed, and the accompanying files are not affected.

[0083] For example, when a file is deleted upstream, the custom modifications scattered throughout the file are lost in related technologies; in this embodiment of the disclosure, only one import line needs to be processed, and the accompanying files are not affected.

[0084] For example, when an upstream file is renamed, in related technologies, all the scattered custom modifications need to be manually migrated; in this embodiment of the disclosure, the import path is updated and the accompanying file is renamed.

[0085] For example, when a new function is added downstream, in related technologies, code is inserted into the upstream file; in this embodiment of the disclosure, a .pink.ts file is added or created in the companion file.

[0086] In some embodiments, when a complete functional module (including service interface definition, main process implementation, IPC channel, rendering process client, etc.) needs to be added downstream, this embodiment completes the integration using the companion file mode, with zero modification to the upstream files. The following example of adding a cocosBuilder module demonstrates the complete integration steps. The entire process includes five steps: Step 1 (Creating Custom Module Directories and Files): Create a `cocosBuilder / ` directory under `src / vs / platform / `, organizing subdirectories according to the upstream layering specification. In the `common / ` directory, create `cocosBuilder.pink.ts` (defining the `ICocosBuilderService` service interface) and `cocosBuilderIpc.pink.ts` (defining the IPC Channel and Client); in the `electron-main / ` directory, create `cocosBuilderMainService.pink.ts` (implementing the main process service logic). All files use the SUD copyright header.

[0087] Step 2 (Registering the service at the main process entry point): Add an import statement and a registerSingleton() call to the existing main process entry point's companion file app.pink.ts to bind the ICocosBuilderService interface to the CocosBuilderMainService implementation class. This step does not modify the upstream app.ts file.

[0088] Step 3 (Register IPC Channel): Append the IPC Channel registration code to the same app.pink.ts companion file to register the CocosBuilderChannel to the main process's IPC service. The IPC Channel ID follows a four-layer naming convention and uses cocos-builder as the channel identifier.

[0089] Step 4 (If RPC proxy is required): If the new module needs to expose APIs in the extended host process, add an RPC Proxy identifier definition to the existing extHost.protocol.pink.ts companion file. The RPC Proxy ID follows a four-layer naming convention and uses MainThreadPinkBuilder as the identifier.

[0090] Step 5 (if rendering process access is required): Append the rendering process-side service singleton registration to the existing workbench.desktop.main.pink.ts companion file. The DI Service ID follows a four-layer naming convention.

[0091] Throughout the entire process, zero lines of modification were made to the upstream files. All new code was added to the .pink.ts file, and all registration operations were appended to the existing companion files. The development cost of the new module was only to implement its own business logic; there was no need to understand or modify the upstream startup process.

[0092] In some embodiments, this disclosure provides a large codebase fork maintenance apparatus, such as... Figure 8 As shown, the large codebase fork maintenance device 60 may include: a creation module 601 and a writing module 602, wherein, Create a module to create a companion file in the folder containing the upstream original files. The companion file has the same name as each upstream original file and the same suffix as the preset suffix. The write module is used to write custom functionality code into each companion file and add side-effect import statements to each upstream original file.

[0093] In some embodiments, a labeling module is also included; The annotation module is used to annotate the modified code using three-level tags when the upstream original file must be modified; The three levels of tags include single-line tags, single-line tags with descriptions, and code block tags.

[0094] In some embodiments, all companion files have the same default file extension.

[0095] In some embodiments, a joining module is also included; The add module is used to add an identifier with a target prefix to the custom function code. The identifier with the target prefix is ​​different from the identifier in the upstream original file.

[0096] In some embodiments, the identifiers include: inter-process communication channel identifier, remote procedure call agent identifier, dependency injection service identifier, and extended contribution point identifier.

[0097] In some embodiments, the modified upstream original file retains the upstream copyright header; the accompanying file uses the downstream copyright header.

[0098] In some embodiments, the directory structure of the customized function code is the same as the directory structure of the upstream original file.

[0099] The apparatus of this disclosure embodiment can execute the method provided in this disclosure embodiment, and its implementation principle is similar, and it has corresponding technical effects. The actions performed by each module in the apparatus of each embodiment of this disclosure correspond to the steps in the method of each embodiment of this disclosure. For a detailed functional description of each module of the apparatus, please refer to the description in the corresponding method shown above, and it will not be repeated here.

[0100] This disclosure provides an electronic device (computer apparatus / device / system) including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method provided in any optional embodiment of this disclosure.

[0101] In one alternative embodiment, an electronic device is provided, such as Figure 9 As shown, Figure 9 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this disclosure.

[0102] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0103] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0104] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0105] The memory 4003 is used to store computer programs that execute embodiments of the present disclosure, and is controlled by the processor 4001 to execute them. The processor 4001 is used to execute the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0106] This disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0107] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0108] It should be understood that although arrows indicate various operation steps in the flowcharts of the embodiments of this disclosure, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this disclosure, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured as required, and the embodiments of this disclosure do not limit this.

[0109] The above description is only an optional implementation method for some implementation scenarios of this disclosure. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this disclosure without departing from the technical concept of this disclosure also fall within the protection scope of the embodiments of this disclosure.

Claims

1. A method for maintaining a large codebase through forking, characterized in that, include: Create a companion file in the folder containing the upstream original files, with the same name as each upstream original file and the default suffix; Write the custom functionality code into each companion file and add a side effect import statement to each upstream original file.

2. The method for maintaining a large codebase fork according to claim 1, characterized in that, The method further includes: When the upstream source file must be modified, use level 3 tags to comment out the modified code; The three levels of tags include single-line tags, single-line tags with descriptions, and code block tags.

3. The method for maintaining a large codebase fork according to claim 1, characterized in that, All accompanying files have the same default file extension.

4. The method for maintaining a large codebase fork according to claim 1, characterized in that, The method further includes: Add an identifier with a target prefix to the custom function code, which is different from the identifier in the upstream original file.

5. The method for maintaining a large codebase fork according to claim 4, characterized in that, The identifiers include: inter-process communication channel identifier, remote procedure call proxy identifier, dependency injection service identifier, and extended contribution point identifier.

6. The method for forking and maintaining a large codebase according to claim 1, characterized in that, Modified upstream original files retain the upstream copyright header; accompanying files use the downstream copyright header.

7. The method for maintaining a large codebase fork according to any one of claims 1 to 6, characterized in that, The directory structure of the customized function code is the same as that of the upstream original file.

8. A large codebase fork maintenance device, characterized in that, include: Create a module to create a companion file in the folder containing the upstream original files. The companion file has the same name as each upstream original file and the same suffix as the preset suffix. The write module is used to write custom functionality code into each companion file and add side-effect import statements to each upstream original file.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images