Application Service Guide > Model Repository Service > Repository Object Administration
  

Repository Object Administration

The Model repository locks objects to prevent users from overwriting work. The Model repository can lock any object that the Developer tool or the Analyst tool displays, except for projects and folders.
You can manage locked objects in a Model repository that is not integrated with a version control system. You can manage checked out objects in a Model repository that is integrated with a version control system. When the Model repository is integrated with a version control system, you can view, undo, or re-assign the checked-out state of an object.

Objects View

You can view and manage repository objects from the Objects tab of the Model Repository Service.
The following image shows the Objects tab with a filter on the Type column: The Objects tab lists repository objects when you apply a filter to the view.
Note: If a Model repository is not integrated with a version control system, the Checked out on column is replaced with Locked on, and the Checked out by column is replaced with Locked by.
When you manage Model repository objects, you filter the list of objects and then select an action:
  1. 1. When you open the Objects tab, the display is empty. Enter filter criteria in the filter bar and then click the Filter icon to get a list of objects to manage. For example, to display a list of objects with Type names beginning with "ma," type ma in the filter bar, and then click the Filter icon.
  2. 2. Select one or more objects. Then right-click a selected object and select an action, or click one of the action icons.
To reset the Objects tab, click the Reset Filter icon.

Locked Object Administration

If the Developer tool or the Analyst tool shuts down, or if the Model repository becomes unavailable, objects retain locks. After the Model repository becomes available, you can view locked objects and unlock them.
You might want to unlock objects if the user who locked them is unavailable and another user is assigned to edit them.
You can perform the following operations:
List locked objects.
You can list the objects that are locked in the Model repository. You can filter the list by the time that a user locked the object. You might want to do this to identify the developers working on each object.
Unlock an object.
You can unlock any object that is locked in the Model repository.
Note: When you unlock a locked object that a user edited, the changes are lost.

Versioned Object Administration

If a developer is not available to check in a checked-out object, you can list and undo or reassign the checked-out state of an object.
You can view objects that are locked or checked out by all users. You can select locked objects and unlock them so that another user can edit them. You can select checked out objects and undo the checked-out state, or assign the checked-out state to another user.
You can perform the following operations:
List checked-out objects.
You can list the objects that are checked out from the Model repository. You can filter the list by the time that a user checked out the object. You might want to do this to identify the developers working on each object.
Check in an object.
You can check in any object that is checked out from the Model repository.
Undo the checkout of a checked-out object.
When a developer has checked out an object from the Model repository and is unavailable to check it in, you can undo the checkout. When you undo the checkout of an object that a user edited, the changes are lost.
Note: If a user moved an object while it was checked out and you undo the checkout, the object remains in its current location, and its version history restarts. Undoing the checkout does not restore it to its pre-checkout location.
Reassign the ownership of checked-out objects.
You can reassign ownership of a checked-out object from one user to another. You might want to do this if a team member goes on vacation with objects still checked out.
If the owner of a checked-out object saved changes, the changes are retained when you reassign the object. If the changes are not saved, the changes are lost when you reassign the object.

Versioned Object Administration Example

You are the Model repository administrator for a development team. One of the team members, abcar, begins an extended, unexpected absence. The user had objects checked out when the absence began.
To assign the checked-out objects to other team members, complete the following steps:
  1. 1. Filter the list of checked out objects to list all the objects that abcar has checked out.
  2. 2. Select some objects and undo the checkout.
    3. The objects are checked in to the Model repository, and any changes that abcar made are lost.
  3. 3. Select the remainder of the objects and reassign them to user zovar.
    4. Any changes that abcar made are retained. User zovar can continue development on the objects, or check in the objects without additional changes. User zovar can also choose to undo the check-out of the objects and lose any changes that abcar made.

Troubleshooting Team-based Development

Consider the following troubleshooting tips when you use features related to team-based development:
The Perforce version control system fails to check in some objects, with an error about excessively long object path names.
Due to Windows OS limitations on the number of characters in a file path, Model repository objects with long path and file names fail when you try to check them in. The Perforce error message reads "Submit aborted" and says the file path exceeds the internal length limit.
To work around this problem, limit the length of directory names in the path to the Perforce depot, and limit the length of project, folder, and object names in the Model repository. Shorter names in all instances help limit the total number of characters in the object path name.
Alternatively, you can install Informatica or the Perforce instance on non-Windows hosts that do not have this limitation.