Considerations for partitioning a repository

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.