Repository FAQLast Updated: 05/04/2018 Introduced in Version:
Q: Where do I set the repository on a development server?
A: On a development server, the repository setting is found in System > Settings > Designer Repository Settings
Typically, you should click the Show Repository Actions option when setting up your repository. This causes repository actions to appear in the action menu of any project folder or entity on your development server.
Q: What are the hardware specs for a Decisions repository server?
A: A repository server should meet the same standards as a Decisions development server. Depending on the size and scope of your projects, the repository server may require additional storage space to accommodate many iterations of project branches.
Q: What structure should I use between my repository, development, and QA servers?
A: You can find a structure that works for you, but Decisions recommends the following. Center all development work on your development server. When it’s time to go to QA, make a branch of your project and check it into the repository. (It is helpful if you establish a concrete QA process that enforces a branch at a certain point followed by clearly defined tests.) On the QA server, check-out the branch and do not allow changes to be checked back in from the QA server. Report issues to the development team so they can continue to develop the next branch. If QA breaks the branch completely, they can go back and pull that branch again and know it is the same as before.
If during testing there are some fixes that must go on the QA branch, create a duplicate of the project before checking in.
Another possibility would be, if you have a UAT environment, you can make a branch off the QA branch and pull it down onto another testing server.
In any case, we recommend never checking in builds from any server other than development.
Q: What versions of a repository are compatible with what versions of Decisions?
A: The best practice is to use the same version for your repository and development servers. At the very least, your repository should be as current or more current than your development server version. Do not use an older repository version with a newer development version. A newer development server may expect services that do not exist on an older repository version (for example, using a 5.0 dev server with a 4.0 repository).
Q: I got the following error: “The commit failed with errors. Error updating […] You have to update it”
A: This error most commonly occurs when two or more developers have checked out the same project and tried to check it back in. If two developers have changed a resource and one has already checked the project back in, the later developer will get this error. To resolve, see “How do I merge changes when there is a more recent version in the Repository?”
Q: How do I merge changes when there is a more recent version in the Repository?
A: If two or more developers have checked out the same project and one has checked back in with changes, the other developer(s) will see an alert when they try to check their changes in. In such a case, if the second developer checks in their changes anyway the repository version will be overwritten. The best practice here is to avoid multiple developers working on the same parts of a project at the same time. However, when this occurs, you can manually review and merge two versions.
When you see an alert that a newer version exists, save a copy of the the project you are working on. Then, check out the repository version of the project. This will overwrite the previous version you had on your development machine, but it’s okay because you saved a copy. Review the new repository version you just checked out and add the changes from your copied version, then check it back in to the repository.
Alternately, if it would be easier to merge the repository version into your version rather than the other way around, you can do so and then apply a force check-in. The force check-in overwrites the repository version with your copied project.
Q: What is Force Check-in?
A: Force Check-in overwrites the current repository version of a project with the version you are checking in, regardless of the presence of a newer checked in version. Use this option when you are sure your version represents all the changes you want to make.
Q: How do I delete an entity (resource) from my project?
A: You do this differently depending on what version of Decisions you have. In 4.0, if you log into the repository and click on a branch, you get a report that shows all the resources in the project. You can right-click on the resource and choose Delete [At Revision] or Delete [Remove from Repository]. The first deletes the resource but leaves it as part of the project itself (letting you undelete it if you choose). If you want to delete it from the repository altogether, use the second option. This tells the repository that the resource no longer belongs to the project.
Some Decisions users will create a new branch in the repository for each development cycle. If you use this development strategy and want to delete an entity from a project, you would have to delete from every branch or the repository will think it’s still a part of the overall project. In this case you would want to use the Delete [Remove from Repository] option.
In 5.0, Decisions will remove a resource from every branch if you choose. In a 5.0 repository, when you right-click on a resource you can click Delete. The following dialog opens:
Deleting at revisions removes the resource only from the given revision while deleting from branches removes the resource from all branches as well.
Q: Why would I want to delete a resource?
A: There are lots of reasons why someone would want to delete a resource from a project. Maybe a developer added a resource to the wrong project or maybe you did intend to check it in but then you realize you would rather create a project common resource if it’s used in multiple projects.
Q: How do I remove a backup folder on a project in the repository?
A: To delete a backup folder from a Decisions 5.0 repository, right-click the folder and click Delete Resource from Branches. As a best practice, you should always remove the resources from the client side also to avoid accidentally checking it in again (for example, unit tests associated with a project that are old). (Sometimes resources that appear in the repository do not show up by default on a development server. In the case of hidden resources, such as history folders, you would have change the folder view page report to show hidden objects. Default report is all folder entities, but there is a all folder entities hidden and deleted.)
If you are unsuccessful, contact Decisions support who can walk you through removing resources directly from the Decisions database.
Q: How do I remove changes I don’t want to be checked in?
A: During check-in, Decisions displays a list of changes you’re about to check in (unless there are more than 250; in such a case Decisions 5.0 and later displays low detail). Review the list and make sure each is something you want to check in. If not, you have two options: 1) uncheck the things you don’t want, 2) leave the changes checked and continue with the check in, then remove the resources from the project after the fact then check in again (do this if you’ve already accidentally checked in changes you don’t want).
Q: I’m getting a timeout error – how can I fix this?
A: Depending on the size of your project, check-in or check-out may timeout. In this case the easiest workaround is to try again. If this doesn’t work, try a smaller check in, i.e. don’t check-in everything at once (especially in earlier versions of 4.0). In later 4.0 and 5.0, if Decisions detects more than 250 changes to check-in it goes into a low detail mode. You can choose by type what you’re checking in to limit the commit.
Sometimes a single resource causes a problem and snags the entire commit. As a workaround for this case, check-in everything except that resource and manually update it. To manually update it, export it from your development server then update it in the repository.