Troubleshooting Repository

Overview 

The following 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. These files are in turn used from development to deployment.

For more information on the Decisions Repository, please visit the Repository Overview article.

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. Decisions has a recommended Repository cycle that Internal Developers typically follow. These recommendations are entirely optional.

• 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.
• Establish concrete QA processes that enforce creating a branch at a certain point, followed by clearly defined tests.
• On the QA server, Checkout the Branch and prevent changes from being Checked back into the environment.  Changes that need to be pushed to different branches can utilize the Merge to Branch action.
• 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 the same Branch again.

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 may still be updating or modifying Resources. This error would occur for a developer attempting to check in a Project after the changes have already been committed.

Resolving the error "error calling service method 'UserHasValidCredentialsForRepository"

This error can be resolved by adding the Repository account credentials to the "Other Contact" section in the Decisions account settings.

1. In the Decisions, right-click and edit the Account you wish to configure the Repository credentials.  
2. In the top search bar, type OTHER CONTACT. Select ADD.
3. Set the following and save:
   • Other Contact Type: Decisions Repository Account.
   • Account: Type the username of an account that is already present in the Repository Server.
4. Edit the newly added account under the Other Contact by selecting the pencil on the right. Add the password to the account. Note that the password should match exactly used in the Repository server. Click OK and save. 
5. Perform any repository actions to test.

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

When Projects are checked into the Repository, the latest changes to the Designer Elements will overwrite what is currently stored in the Repository. So, if two or more developers have checked in changes to the same item, the latest change will take precedence.

To prevent work from being lost, it is best practice to have developers avoid working on the same parts of the Project at the same time. Developers will be alerted whenever a check-in occurs.

When there is an alert that a newer version exists:

1. Save a copy of the Project locally.
2. Checkout the updated version of the Project from the Repository. This will overwrite the current version of the Project on the development machine.
3. Compare and add the changes from the locally stored copy of the project, then check it back into the Repository.

Administrators can also manually review and merge the two versions. Another method would be to merge the repository version of the project into the version being checked in using the Force Checkin action.

What is Force Checkin?

Force Checkin overwrites the current Repository Version of a Project with the version 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. This setting can be found in the first window when checking in a project. 

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

Logging into the Repository and selecting a Branch displays a Report of all of the Resources in a Project.

Right-clicking the name of a Resource and selecting the Delete > Delete Resource from the Branches option removes the Resource from all Branches of the Repository.

Some users will create a new Branch in the Repository for each Development Cycle. If this development strategy is used. Resources must be deleted from every Branch of a Project, or they will still be associated with the overall Project.

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 in the Repository. This prevents deleted entities from being included during checkin/out.

Resources from the Repository server will not always appear by default in the Development environment. 

If the Resources to delete do not show up by default on a Development Server. The Report being used must be updated to show hidden entities, such as History Folders.

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

Decisions will show a list of changes that are being made during the check-in. 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 Time Out during the check-in/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 Projects.

It is also possible that a single Resource could cause a problem with the entire commit. To work around this, check in 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.