Warehouse automation conversion and migration method and device for converting from multi-warehouse management to single-warehouse management, computer device and storage medium

Abstract

Embodiments of the present application relate to the technical field of warehouse management, and provide a warehouse automation conversion and migration method, device, computer equipment and storage medium from multi-warehouse management to single-warehouse management, which comprises: performing file and directory configuration; moving the multi-warehouse management directory of the warehouse to be converted to a first staging directory, deleting all single-warehouse management directories and single-warehouse ignore files in the warehouse to be converted; copying a second ignore file to the root directory of the warehouse to be converted, and copying a first ignore file to all empty directories of the warehouse to be converted; copying the second staging directory to the root directory of the warehouse to be converted, and performing a first warehouse submission operation; moving the multi-warehouse management directory temporarily stored in the first staging directory back to the root directory of the warehouse to be converted, and performing a multi-warehouse management update operation; and performing a second warehouse submission operation. The implementation of the method improves the conversion processing efficiency of the warehouse and improves the management effect of the warehouse.

Description

Technical Field

[0001] This application relates to the field of warehouse management technology, and in particular to a method, apparatus, computer equipment, and storage medium for automated conversion and migration of warehouse management from multi-warehouse management to single-warehouse management. Background Technology

[0002] In the field of warehouse management technology, enterprises often adopt multi-warehouse management technology when developing large warehouses. Each module uses an independent warehouse for storage, which is relatively convenient for large companies with sufficient staff.

[0003] However, for small and medium-sized enterprises, the number of R&D personnel is relatively limited. They need to delete redundant configuration files and sub-repositories from the multi-repository management repository obtained from the official website, and then reinitialize it into a single-repository management repository within the company. The subsequent synchronization of the official new version is labor-intensive and prone to file errors, resulting in low efficiency in repository conversion and poor repository management. Summary of the Invention

[0004] This application provides an automated warehouse conversion and migration method, apparatus, computer equipment, and storage medium for switching from multi-warehouse management to single-warehouse management. More specifically, this application provides an automated warehouse conversion and migration method, apparatus, computer equipment, computer storage medium, and computer program product for switching from multi-warehouse management to single-warehouse management, thereby improving warehouse conversion processing efficiency and enhancing warehouse management effectiveness.

[0005] In a first aspect, embodiments of this application provide an automated warehouse conversion and migration method for switching from multi-warehouse management to single-warehouse management, including: Configure the files and directories to obtain the configured first temporary directory, second temporary directory, first ignored file, and second ignored file; Move the multi-warehouse management directory of the warehouse to be converted to the first temporary directory, and delete all single-warehouse management directories and single-warehouse ignored files in the warehouse to be converted; Copy the second ignored file to the root directory of the repository to be converted, and copy the first ignored file to all empty directories of the repository to be converted; Copy the second temporary directory to the root directory of the repository to be converted, and execute the first repository commit operation; Move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and perform a multi-warehouse management update operation. Perform a second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

[0006] Optionally, in some embodiments of this application, the method further includes: An external synchronization branch and an internal synchronization branch are constructed to associate the transformed repository; the external synchronization branch is used to track external remote repositories to synchronize external program updates, and the internal synchronization branch is used to track internal remote repositories to perform program updates; the multi-repository management update operation is executed based on the external synchronization branch; Switch to the internal synchronization branch and perform a repository push operation to push the updated program from the multi-repository management update operation to the internal remote repository.

[0007] Optionally, in some embodiments of this application, the method further includes: In response to a subsequent new synchronization command for an external remote repository, switch to the external synchronization branch, execute the multi-repository management update operation, and execute the first repository commit operation to submit the updated program to the external synchronization branch. Switch to the internal synchronization branch and perform a merge operation to merge the external synchronization branch into the internal synchronization branch; Perform a push operation to push the updated program to an internal remote repository.

[0008] Optionally, in some embodiments of this application, the method further includes: Perform an environmental catalog check to determine the results. If the environment directory check result indicates that any one of the first temporary directory, the second temporary directory, the first ignored file, or the second ignored file is missing, file and directory configuration is performed to automatically create the corresponding environment directory.

[0009] Optionally, in some embodiments of this application, copying the first ignored file to all empty directories of the repository to be converted includes: Based on the file search command in warehouse management, find the file directories with empty directories in the warehouse to be converted, and determine all empty directories in the warehouse to be converted; Based on the pipe symbol instruction in warehouse management, copy the first ignored file to all empty directories of the warehouse to be converted.

[0010] Optionally, in some embodiments of this application, performing the first repository commit operation includes: Execute the selection instruction for the target code file in the repository to be converted, and determine the selected target code file; Execute the target repository commit command to store the selected target code file into the internal remote repository; Execute the tag adding command to determine the tag information for the commit program version stored in the internal remote repository this time.

[0011] Optionally, in some embodiments of this application, the step of performing a second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted includes: Execute the selection instruction for the target code file in the repository to be converted, and determine the selected target code file; Execute the target repository commit command to store the selected target code file into the internal remote repository, so as to obtain the transformed repository corresponding to the repository to be transformed.

[0012] Secondly, embodiments of this application provide an automated warehouse conversion and migration device for switching from multi-warehouse management to single-warehouse management, which has the function of implementing the automated warehouse conversion and migration method for switching from multi-warehouse management to single-warehouse management provided in the first aspect above. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above function, and the modules can be software and / or hardware.

[0013] In one possible design, the device includes: The file and directory configuration module is used to configure files and directories, and obtain the configured first temporary directory, second temporary directory, first ignored file, and second ignored file; The directory moving and file deletion module is used to move the multi-repository management directory of the repository to be converted to the first temporary directory, and delete all single-repository management directories and single-repository ignored files in the repository to be converted. The directory copy processing module is used to copy the second ignored file to the root directory of the repository to be converted, and to copy the first ignored file to all empty directories of the repository to be converted; The first warehouse submission operation execution module is used to copy the second temporary storage directory to the root directory of the warehouse to be converted and execute the first warehouse submission operation; The multi-warehouse management update operation execution module is used to move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and execute the multi-warehouse management update operation. The second warehouse submission operation execution module is used to execute the second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

[0014] In another aspect, this application provides a computer device including at least one connected processor and a memory, wherein the memory is used to store program code, and the processor is used to call the program code in the memory to execute the methods described in the above aspects.

[0015] In another aspect, embodiments of this application provide a computer storage medium including instructions that, when executed on a computer, cause the computer to perform the methods described in the above aspects.

[0016] In another aspect, this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described in the above aspects.

[0017] Compared to traditional technologies, the technical solution of this application embodiment achieves automatic conversion from multiple warehouses to a single warehouse by standardizing directory configuration and file migration processes, improving the efficiency and regularity of warehouse migration, reducing the cost of manual configuration errors, enhancing the adaptability of warehouse version control, thereby improving the efficiency of warehouse conversion processing and improving warehouse management effectiveness. Attached Figure Description

[0018] Figure 1 This is a flowchart of one embodiment.

[0019] Figure 2 This is a flowchart of another embodiment.

[0020] Figure 3 This is a schematic diagram of the migration process in one embodiment.

[0021] Figure 4 This is a structural block diagram of the device in one embodiment.

[0022] Figure 5 This is an internal structural diagram of a computer device in one embodiment.

[0023] Figure 6 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0024] The terms "first," "second," etc., used in the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules appearing in the embodiments of this application is only a logical division. In actual applications, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between modules may be electrical or other similar forms. None of these are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of this application.

[0025] This application applies to the conversion and migration of repositories from multi-repository management to single-repository management. A multi-repository management repository is a unified code repository consisting of multiple independent sub-repositories under a single main management tool, with each sub-repository having independent version control, such as a Repo repository. A single-repository management repository is a code repository containing only one version control directory, with all code managed uniformly and without nested sub-repositories, such as a Git repository.

[0026] Figure 1 This is a flowchart illustrating one embodiment, such as... Figure 1 As shown in the embodiments of this application, the automated warehouse conversion and migration method from multi-warehouse management to single-warehouse management includes: S1 configures files and directories, resulting in the configured first temporary directory, second temporary directory, first ignored file, and second ignored file.

[0027] Among them, file and directory configuration refers to the operation of presetting and creating the required directories and configuration files.

[0028] The first temporary storage directory is a pre-established multi-warehouse management directory used for temporary storage during the migration process. Specifically, the first temporary storage directory is the repo repository.repo temporary storage directory.

[0029] The second temporary directory is a pre-established directory used for subsequent management of the converted repository. Specifically, the second temporary directory is the .git temporary directory of the converted git repository.

[0030] The first ignore file is used to specify files in an empty directory that do not require version control. Specifically, the first ignore file is a public empty .gitignore file.

[0031] The second ignore file is used to specify files in the repository root directory that do not require version control. Specifically, the second ignore file is the .gitignore file of .repo that is ignored.

[0032] In addition, it should be noted that the steps in the automated warehouse conversion and migration method of this application can be implemented using an automated script program. After the first temporary storage directory, the second temporary storage directory, the first ignore file, and the second ignore file are established, they can be stored in the corresponding location of the script program to be executed, so that the script program can call them directly when it is executed.

[0033] S2: Move the multi-warehouse management directory of the warehouse to be converted to the first temporary directory, and delete all single-warehouse management directories and single-warehouse ignored files in the warehouse to be converted.

[0034] Among them, the repository to be converted refers to the source code repository for which the multi-repository to single-repository migration is to be performed. For example, the repository to be converted is the repo repository.

[0035] The multi-repository management directory is the configuration root directory used to manage multiple sub-code repositories. For example, the multi-repository management directory is the .repo directory of the repo repository.

[0036] Among them, the single repository management directory refers to the hidden version control directory that comes with the repository. For example, the single repository management directory is all the .git directories in the repo repository.

[0037] Among them, files to be ignored in a single repository are files that are excluded from committing in the version control of a single repository. For example, files to be ignored in a single repository are the .gitignore files in the repo repository.

[0038] S3, copy the second ignored file to the root directory of the repository to be converted, and copy the first ignored file to all empty directories of the repository to be converted.

[0039] The root directory is used to represent the top-level program file storage directory of the repository hierarchy. The root directory of the repository to be transformed is also called the repo repository directory, the repo repository root directory, or the root directory that needs to be managed by git.

[0040] Among them, all empty directories in the repository to be converted refer to all blank folders in the repository that have no business code but only retain the directory structure.

[0041] S4, copy the second temporary directory to the root directory of the repository to be converted, and execute the first repository commit operation.

[0042] The first repository commit operation refers to the version archiving operation after the initial solidification of the directory configuration. Specifically, performing the first repository commit operation includes executing `git add`, `git commit`, and `git tag`.

[0043] S5: Move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and perform the multi-warehouse management update operation.

[0044] Among them, the multi-repository management update operation is used to synchronize external source code versions to the local repository, specifically by executing the reposync update operation.

[0045] S6, execute the second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

[0046] The second repository commit operation refers to the secondary version archive action after restoring the management directory, such as executing gitadd && git commit.

[0047] The transformed repository represents the complete source code repository after the multi-to-single migration is completed. The transformed repository is the repository that has been transformed to implement the dual management mode of repo sub-repository and git main repository. The transformed repository can be used for both Git management and repo synchronization updates, achieving a perfect combination of the two management modes.

[0048] Compared to traditional technologies, in this embodiment, the process first involves configuring files and directories, then moving the multi-repository management directory to the first temporary directory, deleting all single-repository management directories and single-repository ignored files, copying the second ignored files to the root directory, copying the first ignored files to all empty directories, copying the second temporary directory to the root directory, performing a first repository commit operation, moving the multi-repository management directory temporarily stored in the first temporary directory back to the root directory, performing a multi-repository management update operation, and finally performing a second repository commit operation to obtain the converted repository. The technical solution of this embodiment, by standardizing directory configuration and file migration processes, achieves automatic conversion from multiple repositories to a single repository, improving the efficiency and regularity of repository migration, reducing the cost of manual configuration errors, enhancing the adaptability of repository version control, thereby improving the efficiency of repository conversion processing and improving repository management effectiveness.

[0049] Figure 2 This is a flowchart illustrating another embodiment, such as... Figure 2As shown in the embodiments of this application, the automated warehouse conversion and migration method from multi-warehouse management to single-warehouse management also includes: S7 constructs the external and internal synchronized branches associated with the transformed repository.

[0050] Among them, the external synchronization branch, also known as the sync branch, refers to the dedicated version synchronization branch line that connects to the external source code source. The external synchronization branch is used to track the external remote repository to synchronize external program updates. The external remote repository refers to the remote repository that provides source code version updates from the original manufacturer.

[0051] Among them, the internal synchronized branch, also known as the local branch, refers to the dedicated development branch line that connects to the enterprise's internal repository. The internal synchronized branch is used to track the internal remote repository for program updates. The internal remote repository refers to the private remote repository within the enterprise that stores custom code.

[0052] Provided that the external synchronization branch and the internal synchronization branch are successfully established in step S7, the multi-warehouse management update operation in step S5 can be executed based on the external synchronization branch.

[0053] S8, switch to the internal synchronization branch, and perform a repository push operation to push the updated program from the multi-repository management update operation to the internal remote repository.

[0054] The repository push operation refers to the synchronous action of uploading local branch code to a remote repository, such as executing gitpush.

[0055] In this embodiment, by setting up dual synchronous branches to connect to internal and external remote repositories respectively, the source code synchronization is isolated from the internal development process, thereby improving the stability of code version synchronization, improving the management order of repository branches, and enhancing the source code iteration control capabilities.

[0056] The following section describes the specific steps of the automated warehouse conversion and migration method from multi-warehouse management to single-warehouse management provided in this application embodiment from the perspective of other technical descriptions, taking the warehouse to be converted as a Repo management warehouse and the converted warehouse as a modified Git management warehouse with dual management methods as an example.

[0057] Step S1 can also be described as: checking the environment directory, which mainly includes the repo repository .repo temporary directory, the converted git repository .git temporary directory (an initial new repository used for subsequent management of the converted repository), the public .gitignore empty file (manually configured in advance), and the .gitignore file that ignores .repo (manually configured in advance).

[0058] Based on step S1, determine whether an environment directory is required; if not, automatically create the corresponding environment directory.

[0059] Step S2 can also be described as: moving the .repo directory of the repo repository to the .repo temporary directory, and deleting all .git directories and .gitignore files in the repo repository.

[0060] Step S2 is crucial. If S2 is not executed, subsequent `git add` commands will result in issues such as uploading the `.repo` file, nested `git` commands, and lost directories.

[0061] The reason for deleting all .git directories and .gitignore files in the repo repository is as follows: Due to some historical reasons, some .gitignore files in the repo repository may ignore some useful files due to errors in writing or other reasons. If these files are not deleted first, it will be impossible to add these useful files to the git repository in step S4. See step S5 for details.

[0062] For example, the programming language expression for step S2 can be: find . / -name ".git" | xargs rm -rf; find . / -name ".gitignore" | xargs rm -rf; Step S3 can also be described as: copying the .gitignore file that ignores .repo to the repo repository directory, and using the find command to search for directories with empty files, and using the pipe symbol to copy the empty .gitignore (the common empty .gitignore file) to all empty directories.

[0063] If step S3 is not performed, the empty directory will not be added to the git management system and will not be able to be uploaded to the remote repository.

[0064] The empty .gitignore file in the .repo repository is ignored because some sub-git repositories within the repo-managed code repository contain empty repositories. Although empty, these empty repositories are still dependent on during compilation and cannot be completely deleted. In step S2 above, after deleting the .git file of the sub-repository, the corresponding repository becomes an empty directory. Empty directories cannot be included in Git management, causing them to be automatically discarded when pushed to the remote repository. Therefore, in step S3, an empty .gitignore file is added to the empty directory, allowing it to be added to Git.

[0065] For example, the programming language expression for step S3 can be: find . / -type d -empty | xargs -i cp .. / .. / git_empy_ignore / .gitignore{} -rf; Step S4 can also be described as: Copy the temporary .git directory (the temporary .git directory of the converted git repository) to the root directory that needs to be managed by git (the original root directory of the repo repository, the purpose of which is to make the preprocessed repo repository a complete Git repository), and execute git add, git commit, and git tag to completely commit the added repo repository to the local commit.

[0066] The `git add` option selects all ".git" files. git commit: Officially commits the selected files to the internal Git repository; `git tag`: Tag the version you've committed for easy identification later.

[0067] Step S5 can also be described as: moving the .repo directory backed up in step S2 back to the original directory (the root directory of the original repo repository), and then performing the repo sync update operation.

[0068] Step S5 will regenerate the .git and .gitignore files deleted in step 2. When performing the git add operation, there will be no error message indicating nested commits. Furthermore, .gitignore files in subdirectories will also be included in version control, and they will not be excluded from version control due to directories that are ignored in the native repo repository.

[0069] Step S6 can also be described as: Execute `git add && git commit` again.

[0070] In step S6, version tags are not needed this time, as this does not involve a major version update. Tagging is only required for subsequent major version updates. This step mainly involves adding the .gitignore file from the original repo repository to Git management.

[0071] Git has this rule: once a directory structure is incorporated into a new .git directory, the .git files under that directory will not be nested. However, if the directory structure is not initially incorporated into the new .git directory, `git add directory` will prompt a nesting error. Therefore, you need to delete the .git files in the directory first, and then restore the deleted .git files later, mainly for use in subsequent major version updates.

[0072] Step S7 can also be described as: Checkout a branch that tracks external remote repositories and is used to update and synchronize external SDK updates (referred to as the sync branch), and a branch that tracks internal remote git repositories and is used to synchronize internal remote repositories (referred to as the local branch).

[0073] This allows a single SDK to manage the entire repository (repo) via git, and the .git subdirectory under repo can also fully retain git records.

[0074] Branch switching is a Git feature that requires maintaining a clean branch specifically for synchronizing remote repositories, and then switching to a local branch specifically for synchronizing internal company repositories. This way, updating and synchronizing remote repositories can be done automatically using the `git merge` command without having to compare differences file by file, eliminating the need for manual comparison.

[0075] Step S8 can also be described as: Switch to the local branch and execute `git push` to the remote branch within the company.

[0076] This way, the remote Git repository is a pure code repository without .repo or sub-repository .git.

[0077] Optionally, in some embodiments of this application, the method further includes: in response to a subsequent new synchronization instruction for an external remote repository, switching to an external synchronization branch, performing a multi-repository management update operation, performing a first repository commit operation to submit the updated program to the external synchronization branch; switching to an internal synchronization branch, performing a merge operation to merge the external synchronization branch into the internal synchronization branch; and performing a push operation to push the updated program to the internal remote repository.

[0078] The new synchronization commands for external remote repositories refer to commands used to trigger the retrieval of new versions of code from external remote repositories.

[0079] The merge operation refers to the action of merging external branch code into an internal development branch, such as the merge operation.

[0080] For example, if you need to synchronize an external remote repository to your local machine later, simply switch to the sync branch, execute the reposync operation to update the code to the latest version; then execute git add, git commit, and git tag to commit the code to the sync branch; then switch to the local branch, execute the merge operation to merge the sync branch into the local branch; finally, push to the company's internal remote repository, thus completing the code update operation.

[0081] In this embodiment, the external source code is seamlessly synchronized to the internal repository through the linkage process of branch switching and code merging, which improves the efficiency of version iteration, reduces the probability of code merging conflicts, and enhances the continuous update and adaptation capabilities of the source code.

[0082] Optionally, in some embodiments of this application, the method further includes: performing an environment directory check to determine the environment directory check result; and configuring files and directories to automatically create the corresponding environment directory if the environment directory check result indicates that any directory or file in the first temporary directory, the second temporary directory, the first ignored file, or the second ignored file is missing.

[0083] The environment directory check and processing refers to the operation of verifying whether the directory files required for migration are complete, such as determining whether an environment directory is required.

[0084] The environmental directory check results are used to reflect the completeness of the basic directory files required for migration.

[0085] For example, it is determined whether an environment directory is required. If not, the corresponding environment directory is automatically created. The automatic creation of the corresponding environment directory includes automatically creating any missing items in the first temporary directory, the second temporary directory, the first ignored file, and the second ignored file.

[0086] In this embodiment, the pre-process environment verification and automatic replenishment mechanism avoids the problem of migration interruption due to missing catalogs, improves the stability of the warehouse migration process, and reduces the operation and maintenance costs of manual environment inspection.

[0087] Optionally, in some embodiments of this application, copying the first ignored file to all empty directories of the repository to be converted includes: searching for empty file directories in the repository to be converted based on file search commands in the repository management, and determining all empty directories in the repository to be converted; and copying the first ignored file to all empty directories in the repository to be converted based on pipe operator instructions in the repository management.

[0088] Among them, the file search command is used to traverse and search for files in the repository that meet certain conditions, such as the find command.

[0089] Among them, the pipe symbol instruction is a control symbol instruction used to chain preceding and following commands and pass the execution result.

[0090] For example, the find command is used to find directories with empty files, all empty directories of the repository to be converted are identified, and the common empty .gitignore file is copied to all empty directories using a pipe.

[0091] In this embodiment, the file search command and the pipe instruction are linked to configure ignored files in batches, which improves the execution efficiency of empty directory configuration, reduces the tedious problem of manual configuration one by one, and enhances the batch directory processing capability.

[0092] Optionally, in some embodiments of this application, performing a first repository submission operation includes: executing a selection instruction for a target code file in the repository to be converted, and determining the selected target code file; executing a target repository submission instruction to store the selected target code file in an internal remote repository; and executing a tag adding instruction to determine the tag information of the submission program version stored in the internal remote repository this time.

[0093] Among them, the selection command is the operation command used to select the target code file to be included in version control, such as gitadd.

[0094] The target code files refer to the business and configuration program files in the repository that participate in version commits, such as all ".git" code files.

[0095] The target repository commit command is the execution command used to solidify the selected files into version records, such as git commit.

[0096] The tag addition command is used to annotate version commit records with version identifiers, such as `git tag`. The tag information is the program version identifier corresponding to this code commit.

[0097] In this embodiment, by binding file selection and submission with version tags, migration version information is accurately solidified, improving the convenience of version tracing, addressing the problem of disordered version management, and enhancing the repository's version traceability capabilities.

[0098] Optionally, in some embodiments of this application, performing a second repository submission operation to obtain a converted repository corresponding to the repository to be converted includes: executing a selection instruction for target code files in the repository to be converted to determine the selected target code files; executing a target repository submission instruction to store the selected target code files in an internal remote repository to obtain a converted repository corresponding to the repository to be converted.

[0099] In this embodiment, since no major version update is involved, the tag addition command was not used, which improved the execution efficiency. The .gitignore of the original repo repository was added to the git management, completing the final adjustment of the converted repository.

[0100] The technical research process and other technical details of this application are described below with reference to a specific embodiment.

[0101] In traditional technologies, enterprises typically manage large-scale repository SDKs using multiple repositories, such as the current Android SDK. Each module has its own independent repository, and developers responsible for a particular functional module often need to focus on multiple sub-modules within that repository (the code for a software function is scattered across multiple Git repositories, requiring developers to maintain multiple Git repositories simultaneously). This dispersed nature is indeed convenient for large companies with well-structured staffing, as they only need to focus on their assigned functional modules and related sub-modules.

[0102] For small and medium-sized enterprises, R&D personnel are relatively limited. Generally, one engineer needs to be responsible for multiple modules, and more commonly, they need to be familiar with the entire SDK code. Therefore, it is usually necessary to delete redundant repositories (delete the configuration files used to aggregate sub-repositories in the "repo multi-repository management" tool) and sub-repositories from the official repository with repo. That is, delete all .repo and .git directories that occupy space in the original repository, and then reinitialize the entire SDK into an internal company Git repository (reinitialize the entire code into a new Git repository). Subsequently, when synchronizing major versions from the official repository, it is necessary to compare the major version SDK differences with the internal company Git repository (after updating the major version, first compare the differences between the new version and the old version from the official repository, and then check if there are any sub-repositories that the company is interested in from the difference repositories, and then add these sub-repositories to the internal company Git repository). The workload of the entire process is very large. Millions of files are prone to errors, especially in the early stages when major version updates are frequent. If this development model is followed, the work of updating and merging the SDK will waste a lot of R&D resources and energy.

[0103] In small and medium-sized technology enterprises and startups, the high degree of reuse of R&D resources is the norm. Due to limited staff, engineers often need to collaborate across modules and multiple repositories. If the traditional multi-repository management model is directly adopted in this environment, significant bottlenecks will be revealed: complex dependencies of manifest files, scattered permission control, and time-consuming cross-repository synchronization operations have become invisible shackles restricting the improvement of R&D efficiency.

[0104] In the existing technology, the migration from Repo to Git mainly relies on manual operation, which has the following technical defects: (1) Low migration efficiency: It is necessary to manually process each sub-repository one by one. For large projects containing hundreds of sub-repositories, the migration process takes several days or even weeks; (2) Difficulty in ensuring data consistency: Manual operation is prone to missing specific branches, tags or commit history, resulting in incomplete repository data after migration, and it is impossible to completely retain all the git commits of the original repo repository; (3) Difficulty in maintaining version relationships: There are strict version dependencies between the sub-repositories managed by Repo, and it is difficult to accurately maintain this synchronization relationship during manual migration; (4) High error rate and difficult to troubleshoot: Operational errors during the migration process may lead to the loss of code history, and the cost of locating the problem is high.

[0105] Based on this, this application provides an automated conversion and migration method for warehouses from multi-warehouse management to single-warehouse management. It can also be called a script technology for quickly converting repo-managed warehouses to git-managed warehouses, or a method for automated migration of warehouses across version control systems using a shell script. For ease of description, it can be simply referred to as the automated conversion and migration method for warehouses in this application.

[0106] The automated conversion and migration method for repositories proposed in this application solves the problems of low migration efficiency, easy errors, and poor data consistency in existing technologies, and implements a dual management mode of repo sub-repositories and git main repository, thereby improving update efficiency.

[0107] The advantages of the automated conversion and migration method of this application are: (1) High degree of automation: The entire repo repository to git repository conversion is carried out by script automation, which overcomes the hidden dangers caused by the easy omission of files in manual operation and solves the problems of complexity and low efficiency of manual operation; (2) Strong compatibility: Supports specific architectures of chip manufacturers such as SPRD and Allwinner; (3) Supports offline / online dual mode, adapting to the enterprise's internal and external network development environment; (4) Non-intrusive migration: The original Repo project structure is retained, and only the version control metadata is converted. It realizes that a set of SDKs can record the internal commit records of the company and completely retain the git records of the original repo repository. Moreover, the repository of the company's internal remote server is a single git repository without repo and sub-git, which greatly reduces the code storage space (A16 code is reduced from 1T to 120GB). In a company of general size, single git management is convenient and fast, improves efficiency, and reduces storage costs.

[0108] The automated repository conversion and migration method proposed in this application adopts the unique approach of Git management of repo repositories; it completes the update from the external remote repository to the internal remote repository by establishing external and internal remote tracking branches; it automatically preserves the original Repo configuration of each SDK layer (sys / vnd / kernel), automatically generates and injects Git standard ignore rules, and eliminates redundant commits.

[0109] The following describes the overall system architecture and module interactions of the automated repository conversion and migration method proposed in this application. The overall system architecture mainly consists of an environment initialization module, a metadata backup module, and a Git refactoring module. The environment initialization module is responsible for creating temporary directories, parsing parameter configurations, and adapting to network modes. The metadata backup module is used to identify the .repo structure, formulate conditional migration strategies, and retain permissions and configurations. The Git refactoring module implements cloning of empty Git projects, branch and tag management, and commit tree reconstruction. These modules work together to complete the temporary directory creation, metadata detection, and Git project initialization process, achieving automated conversion from a multi-repository Repo project to a single-repository Git project.

[0110] Figure 3 This is a schematic diagram of the migration process in one embodiment, illustrating the principle of the state machine for the Repo to Git migration process. Specifically, after executing the automated script corresponding to the automated repository conversion and migration method of this application, the process enters the environment initialization unit, completing the Repo project structure detection, receiving configuration parameters, and creating a three-level temporary isolation directory; then it enters the repository Git reconstruction stage, sequentially completing the metadata transfer state (backing up and restoring the .repo directory and sub-repository .git), the Git standardization state (cleaning up interfering files and injecting ignore rules), and the branch reconstruction state (creating update synchronization branches and local branches, and rebuilding the commit history). Finally, it executes again to ensure that the code is up-to-date, realizing the standardized conversion from the Repo project to a single repository Git.

[0111] The final directory structure and branch structure of the SDK repository for the automated conversion and migration method of this application are described below.

[0112] The final directory structure of the converted repository is as follows: Android SDK; ├── .git; ├── .repo; ├── .gitignore; ├── device; ├── external; ├── frameworks; ├── tools; ├── vendor; ... The final transformed repository corresponds to the external and internal synchronized branches. The branching structure is as follows: a523_androidt; a523_t connects to a local remote repository branch; a523_t_teclast_sync: Connects to an external original manufacturer remote branch.

[0113] Here, a523_androidt is the overall project name, representing the company's products based on the A523 platform and AndroidT system. a523_t is the branch used internally by the company (internal synchronization branch); a523_t_teclast_sync (with...) The number indicates the branch currently in use (the branch that synchronizes with the official source code, or the external synchronization branch).

[0114] It should be noted that any technical feature in any of the above embodiments provided in this application is also applicable to any of the following embodiments provided in this application; the technical features in the relevant embodiments of the various methods provided in this application are also applicable to the relevant embodiments of the various devices, systems or equipment provided in this application; the same, related or corresponding technical features in the various embodiments provided in this application can be referenced and explained to each other, and similarities will not be repeated.

[0115] Figure 4 Here is a structural block diagram of the device in one embodiment, with reference to Figure 4 The automated warehouse conversion and migration device for shifting from multi-warehouse management to single-warehouse management includes: The file and directory configuration module 401 is used to configure files and directories to obtain the configured first temporary directory, second temporary directory, first ignored file, and second ignored file; The directory moving and file deletion module 402 is used to move the multi-repository management directory of the repository to be converted to the first temporary directory, and delete all single-repository management directories and single-repository ignored files in the repository to be converted. The directory copy processing module 403 is used to copy the second ignored file to the root directory of the repository to be converted, and to copy the first ignored file to all empty directories of the repository to be converted; The first repository commit operation execution module 404 is used to copy the second temporary storage directory to the root directory of the repository to be converted and execute the first repository commit operation; The multi-warehouse management update operation execution module 405 is used to move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and execute the multi-warehouse management update operation. The second warehouse submission operation execution module 406 is used to execute the second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

[0116] In this embodiment of the application, based on, as follows Figure 4 The connections between the various modules or units shown in the diagram improve the efficiency of warehouse conversion and processing, and enhance warehouse management effectiveness through the cooperation between these modules or units.

[0117] In another embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, it includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores relevant data. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. The computer program can be executed by the processor to implement the various methods described in the above embodiments.

[0118] In yet another embodiment, a computer device is provided, such as a terminal, whose internal structure diagram may be as follows: Figure 6 As shown, it includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. The computer program can be executed by the processor to implement the various methods described in the above embodiments.

[0119] Those skilled in the art will understand that Figure 5 and Figure 6 The structure shown is only a block diagram of a part of the structure related to the present application and does not constitute a limitation on the computer device on which the present application is applied. It may also include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements, in order to realize the function of the computer device.

[0120] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0121] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the systems, devices, equipment, modules or units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0123] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0125] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0126] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., a solid-state drive), etc.

[0127] The technical solutions provided by the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. A method for automated conversion and migration of warehouses from multi-warehouse management to single-warehouse management, characterized in that, The method includes: Configure the files and directories to obtain the configured first temporary directory, second temporary directory, first ignored file, and second ignored file; Move the multi-warehouse management directory of the warehouse to be converted to the first temporary directory, and delete all single-warehouse management directories and single-warehouse ignored files in the warehouse to be converted; Copy the second ignored file to the root directory of the repository to be converted, and copy the first ignored file to all empty directories of the repository to be converted; Copy the second temporary directory to the root directory of the repository to be converted, and execute the first repository commit operation; Move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and perform a multi-warehouse management update operation. Perform a second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

2. The method according to claim 1, characterized in that, The method further includes: An external synchronization branch and an internal synchronization branch are constructed to associate the transformed repository; the external synchronization branch is used to track external remote repositories to synchronize external program updates, and the internal synchronization branch is used to track internal remote repositories to perform program updates; the multi-repository management update operation is executed based on the external synchronization branch; Switch to the internal synchronization branch and perform a repository push operation to push the updated program from the multi-repository management update operation to the internal remote repository.

3. The method according to claim 1, characterized in that, The method further includes: In response to a subsequent new synchronization command for an external remote repository, switch to the external synchronization branch, execute the multi-repository management update operation, and execute the first repository commit operation to submit the updated program to the external synchronization branch. Switch to the internal synchronization branch and perform a merge operation to merge the external synchronization branch into the internal synchronization branch; Perform a push operation to push the updated program to an internal remote repository.

4. The method according to claim 1, characterized in that, The method further includes: Perform an environmental catalog check to determine the results. If the environment directory check result indicates that any one of the first temporary directory, the second temporary directory, the first ignored file, or the second ignored file is missing, file and directory configuration is performed to automatically create the corresponding environment directory.

5. The method according to claim 1, characterized in that, The step of copying the first ignored file to all empty directories of the repository to be converted includes: Based on the file search command in warehouse management, find the file directories with empty directories in the warehouse to be converted, and determine all empty directories in the warehouse to be converted; Based on the pipe symbol instruction in warehouse management, copy the first ignored file to all empty directories of the warehouse to be converted.

6. The method according to claim 1, characterized in that, The execution of the first repository commit operation includes: Execute the selection instruction for the target code file in the repository to be converted, and determine the selected target code file; Execute the target repository commit command to store the selected target code file into the internal remote repository; Execute the tag adding command to determine the tag information for the commit program version stored in the internal remote repository this time.

7. The method according to claim 1, characterized in that, The step of performing the second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted includes: Execute the selection instruction for the target code file in the repository to be converted, and determine the selected target code file; Execute the target repository commit command to store the selected target code file into the internal remote repository, so as to obtain the transformed repository corresponding to the repository to be transformed.

8. A warehouse automation conversion and migration device for switching from multi-warehouse management to single-warehouse management, characterized in that, The device includes: The file and directory configuration module is used to configure files and directories, and obtain the configured first temporary directory, second temporary directory, first ignored file, and second ignored file; The directory moving and file deletion module is used to move the multi-repository management directory of the repository to be converted to the first temporary directory, and delete all single-repository management directories and single-repository ignored files in the repository to be converted. The directory copy processing module is used to copy the second ignored file to the root directory of the repository to be converted, and to copy the first ignored file to all empty directories of the repository to be converted; The first warehouse submission operation execution module is used to copy the second temporary storage directory to the root directory of the warehouse to be converted and execute the first warehouse submission operation; The multi-warehouse management update operation execution module is used to move the multi-warehouse management directory of the warehouse to be converted, which is temporarily stored in the first temporary storage directory, back to the root directory of the warehouse to be converted, and execute the multi-warehouse management update operation. The second warehouse submission operation execution module is used to execute the second warehouse submission operation to obtain the converted warehouse corresponding to the warehouse to be converted.

9. A computer device, characterized in that, The computer device includes: At least one processor and memory; The memory is used to store program code, and the processor is used to call the program code stored in the memory to execute the method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, It includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images