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. 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 check in builds from any server other than development.

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 Checkin 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 Checked out 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 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.

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 [Remove from Repository] option removes the resource from all Branches of the Repository.

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.