Repository partitioning requires careful planning on how you want to organize your automation projects.
Review the following considerations before you partition your repository:
- This feature requires that you are a Control Room administrators or a user with the Partition repository permission.
- Every repository partition is like a central storage location for all the
files (bots, processes, dependencies, and so on) that
belong to an automation project.
Ensure that the repository partition permission is available only to a small set of users who are responsible for the automation project.
- You can only partition the folders available in the
Public repository.
Ensure that the folders within the public repository are planned correctly before you proceed with the repository partition.
- After you have partitioned the repository, the action cannot be reversed.
That is, after you have partitioned a folder, this folder cannot be merged back into the main Git folder.
- The repository partition operation can take more time depending on the size of your public repository and the number of commits on your public repository.
- Perform the repository partition operation only during a planned downtime. When your repository is being partitioned, do not perform any repository operations such as check-in, check-out, import, export, promote, recover, move, copy, create, or save because these operations might fail when the repository is being partitioned.
- Repository partition operations can only be performed one after the other as multiple requests are not supported.
- When a folder is partitioned, all the subfolders contained in the folder are retained in the partitioned folder.
- Remote Git repository is not supported in the default Public Git repository.
Any check-in operation done in the partitioned folder is not committed to the remote Git repository.