Repository FAQ

Decisions Repository Server FAQ

This article is used to cover some frequent troubleshooting topics related to the Decisions Repository Server. A Repository server is a central storage location for maintaining Projects, versions, and revisions for builds within Decisions; which are used from development to deployment.

How can a Decisions environment connect to a Repository?

Repository settings can be configured by navigating to System > Settings > Designer Repository Settings in a Decisions environment.

In the window that appears, the Repository URL (including /Primary) must be provided.

What are the hardware specifications for a Decisions Repository Server?

A Repository Server should meet the same standards as a Decisions Development Server.

What kind of process should be used between managing Projects across Repository, Development, and QA Servers?

Every organization has a different process for maintaining its development, testing, and production environments.

• Development should take place on a Development Server, in a Development environment. 

• When the Project is ready for QA, a Branch of the Project should be created in the Repository. This will create a copy of the Project with a Version Number and Name.

• It is helpful to establish a concrete QA process that enforces creating a branch at a certain point, followed by clearly defined tests.

• On the QA server, Checkout 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 release version.

• If QA needs to return to a previous release, 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 be added to the branch that QA is testing, the changes can be moved from the development branch on the Repository into the appropriate branch for testing by using the Merge To Branch action on the Repository.

• Another possibility would be, if a user has a UAT environment, they can make a Branch off the QA branch and pull it down onto another testing server. In any case, it is recommended to never Checkin builds from any server other than development.

What versions of a Repository and Decisions are compatible together?

The best practice is to use the same version for both the Repository and Development servers. At the very least, the Repository should be current to or newer than the Development version. Do NOT use an older Repository version with a newer Development version. A newer Development server may have service Dependencies that do not exist on an older Repository version (i.e. using v6.x in a Development environment and v5.x in a Repository).

How can this error be resolved? "The commit failed with errors. Error updating [...] You have to update it"

This error most commonly occurs when multiple developers check out the same Project and the Project is checked back in (committing changes) while other developers still may be updating or modifying resources. This error would occur for a developer attempting to check in a Project after the Project has already been committed. This is elaborated further in the next question.

How are changes merged when a more recent version of the Project is available in the Repository?

If two or more developers have Checkedout the same Project and one has Checked the Project back in with changes, the other developer(s) will see an alert when attempting to Check their changes in. In such a case, if the second developer checks in their changes regardless, 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. If this occurs, the Administrator can manually review and Merge two versions.

When there is an alert that a newer version exists, save a copy of the Project being worked on and then Checkout the updated Repository Version of the Project. This will overwrite the previous version of the Project on the development machine which is why a copy should be saved. Review the new Repository version that was just Checked out and add the changes from the copied version, then Check it back into the Repository.

If it would be easier to merge the Repository version into the version being checked in, then a Force Checkin can be applied. The Force Checkin overwrites the Repository Version with the copied Project.

What is Force Check-in?

Force Checkin overwrites the current Repository Version of a Project with that is being Checked in, regardless of the presence of a newer Checked in version. Use this option when the user's version represents all the desired changes that will be made.

How can a Designer Element (resource) be Deleted from a Project?

The method by which this is done is dependant on the version of Decisions installed. Typically when logging into the Repository and selecting a Branch, there is a Report that displays all of the Resources in a Project.

Right-click the name of a Resource and select Delete [At Revision] to delete the resource from the Revision but retains it in the Project.

The Delete [Remove from Repository] option removes the Resource from the Repository all together.

Some Decisions users will create a new Branch in the Repository for each development cycle. If this development strategy is used and Resources must be deleted from a Project, it should be deleted from every Branch or the Repository will associate with the overall Project still. In this case, the Delete [Remove from Repository] option should be used.

Why should a resource be Deleted?

There are several scenarios where a Resource may need to be Deleted from a Project. For example, if a developer has added a Resource to the wrong Project or changes to a Resource have been wrongfully Committed, then it may need to be Deleted.

How can backup folders on a Project be Removed?

To Delete a Backup Folder, right-click the Folder Name and select Delete Resource from Branches. As a best practice, always Remove the Resources on the Application side (in a Decisions environment) as well as the Repository, to avoid accidentally Checking it in again. Something like this could occur if there are old Unit Tests associated with a Project, for example. Resources from the Repository server will not always appear by default in the Development environment. To view hidden resources in the Repository.

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, the View of the Page Report must be Changed using the Gear setting icon to show hidden objects. The default Report contains all folder entities, but there is also a hidden folder for all deleted/hidden objects.

How can unwanted Changes that have been Checked in be Removed?

Decisions will show a list of changes that are being made during the Checkin (over 250 changes show in less detail). This list should be thoroughly reviewed so that unwanted changes are Unchecked. In the event that these changes are committed, remove the Resources from the Project and Check it in again.

What is a timeout error and how can it be fixed?

A large Project could Timeout during the Checkin/out process, depending on the actual size. The best action in this scenario would be to try and perform the same action again. If this is still unsuccessful, a smaller Project with fewer resources may need to be Checked in instead; in which case the greater Project would encompass multiple smaller Checked in Projects.

It is also possible that a single Resource could cause a problem with the entire Commit. The workaround for this would be to Checkin everything except the Resource causing an issue, then manually update that Resource. To manually update the Resource, Export it from the Development environment and Upload it to the Repository.

What are sub-Projects?

Sub Projects are a way to organize the Folder hierarchy of Projects on the Repository. There are two ways to create a Sub Project, the first is by Checking in a new Project to the Repository that has the naming convention {Parent Project}.{Sub Project}(Replacing {} with actual Project names).

The other method is on the Repository itself by using the Create Sub Project action.

If a Project with Sub Projects is exported, will the Sub-Projects be exported as well?

The Sub Project feature does not currently operate in this way. The functionality is solely intended for the Folder hierarchy organization. If a Sub Project is created, it only puts that Project within the Folder structure of the Parent Project for folder organization on the Repository; they are functionality separate Projects with no relationship.

Can the Repository be clustered?

No, the Repository was not designed to operate in a Cluster, as features of clustering are not utilized for the Repository.