--- title: "Repository Overview" slug: "repository-overview" description: "This document goes over the Designer Repository in Decisions. The Designer Repository is a Decisions instance that serves as a central location for other servers such as, the Production/QA/Development environments for use for storage/staging Projects. " updated: 2026-04-29T19:59:47Z published: 2026-04-29T19:59:47Z --- > ## Documentation Index > Fetch the complete documentation index at: https://documentation.decisions.com/llms.txt > Use this file to discover all available pages before exploring further. # Repository Overview ## Overview The**Designer Repository** provides a centralized location to promote and store changes to [Designer Projects](/v9/docs/creating-a-project), acting as a form of version control. This is highlighted in the image below, where Projects can be deployed from the repository and shared across different environments. Unlike a traditional **Decisions****Server**, a **Designer Repository** is not used for developing or running applications. ### Features and Highlights - Deploy Decisions **Projects**/**Resources** to different environments from a centralized location. - Store and track changes to Projects through **Revisions** - **Rollback**changes made to Projects to specific Revisions. - Compare the differences between a Project in a linked environment and the copy stored in the Repository. - Maintain different versions of a Project through **Branches** ![](https://cdn.document360.io/6ef8bcc1-6489-4486-9ad1-83acff7e5df0/Images/Documentation/image-1777396400478.png) [Embedded content](https://www.youtube.com/embed/M2Am9gS_L6M) --- ## Advantages of Using the Repository Over Manual Export/Import Using the **Designer Repository** provides several advantages over manually exporting and importing Projects between environments. Manual processes rely on developers to correctly include all required elements, which can lead to inconsistencies or missing components during deployment. - **Reduced Risk of Missing Dependencies** Manual export/import requires explicitly associating all relevant **Designer Elements** with a Project. If any elements are missed, they will not be included in the deployment. The Repository automatically tracks and includes all associated Resources, reducing the risk of incomplete deployments. - **Version Control with Revisions** The Repository maintains a history of changes through **Revisions**, allowing visibility into what was changed and when. Manual export/import does not provide built-in version tracking, making it difficult to manage changes across environments. - **Rollback Capabilities** The Repository allows Projects to be rolled back to a specific **Revision** or point in time. This enables quick recovery from issues introduced during deployment. Manual export/import does not support rollback to a previous state without additional backups. --- ## Deploying Projects to the Repository Server? In version 8, all settings were system-wide. However, in version 9, these settings have been moved inside the Project and have become Project-specific. It is important to note that upgrading from version 8 to version 9 will not move these settings to the Project, even after the [Project conversion](/v9/docs/projects-conversion). Instead, these settings will still be present in the system settings and function as intended in version 8. If users want to make changes to these settings, such as updating the CSS, they will need to move these settings inside the Project using the**"Move Folder to Project"** user action and make the necessary changes. Failing to do so, the changes may not be reflected in the other environment. This is because the changes made in the system settings will not be attached to the Project. Therefore, when the project is checked-in (moved) to the Repository, those changes will not be pushed to the Repository Server. As a result, when checking-out (pulling) the Project from the Repository Server, these changes will not be pulled along with it to the Production Server. In general, the folders in the Manage section of a Project will not export during a check-in. However, anything created through a dependency or a module, such as message handling related folders and scripting (R, Python, etc) will have its folder and contents exported at check-in. Also note that Sub Projects are no longer supported in version 9. --- ## [Repository Actions](/v9/docs/using-the-repository) Once a repository environment is [connected](/v9/docs/connecting-a-decisions-server-to-a-repository-server),**Repository Actions** become available to Designers. These actions can be found by right-clicking a **P****roject Folder**or**Designer Element > Designer Repository,**and provide the tools needed to move a Project between environments. Any**Designer Element**, such as **Flows** or **Rules**, checked into a Repository will be labeled as a **Resource**.**![](https://cdn.document360.io/6ef8bcc1-6489-4486-9ad1-83acff7e5df0/Images/Documentation/Screenshot%202024-03-05%20144827.png)** | Repository Actions | Description | | --- | --- | | Checkin Changes for Project | Checks in the recent changes made to the Project in the copy stored on the repository. | | Checkout updates for the project | Check out a copy of the Project from the Repository. | | Show Project | Displays any recent changes for a specific project in the environment. | | Show All Recent Changes | Highlights any recent changes to all Projects made in the environment | | Revert Changes in Project | Reverts any recent changes to a Project to the copy stored on the Repository. | | Add Dependencies to | Searches for any dependencies that need to be added to the associated Project. | | Remove From Project | Removes the selected element from the Project. | | Checkout Project | Lists all current Projects that can be checked out from the Repository | | Open Repository Server | Opens the Repository server on a new tab. | ### Deleting Resources One of the advantages of using a **Repository**to manage deployments is that it can delete resources from **Projects**as part of a code migration. - When****checking****a Project with deleted **Designer Elements**, the related resource will be marked as deleted in the Repository. - This method is recommended for deleting items from a Project in the Repository. - When checking out a****Project, resources marked as deleted will be removed from the server where the check-out occurs. - The resource will remain in the Repository in a deleted state. The item will not be checked in. --- ## [Branches](https://documentation.decisions.com/v9/docs/repository-branches) **Repository Branches** are used to create a copy of a Project at a snapshot in time. Each Branch maintains a version of all the resources of the Project independently, allowing multiple versions of a **Designer Element** to exist within each branch. Connected servers can only point to one **Branch** for a **Project** at a time. Using Branches does not allow connected servers****to run two versions of the same **Designer Element******simultaneously. Decisions **Repository Trunk / Branch** structure is set up to do all new development work in Trunk and make new Branches as needed. This is opposite to most traditional Repositories, where work is done in a Branch and **Merged**back to the Trunk. --- ## [Revisions](/v9/docs/repository-revisions) A Revision is created each time a change to a Project is checked in/committed to a Repository. Revisions are records of changes made to the Project at the time, similar to [Checkpoints](/v9/docs/creating-checkpoints), but for all **Designer Elements** in a Project. Revisions can be used to create **Branches**for and revert/roll back to earlier versions of the Project within the Repository.![](https://cdn.document360.io/6ef8bcc1-6489-4486-9ad1-83acff7e5df0/Images/Documentation/image-1777492570720.png) --- For further information on Repository, visit the [Decisions Forum](https://community.decisions.com/categories/Repository).