Application Service Guide > Model Repository Service > Version Control for the Model Repository Service
  

Version Control for the Model Repository Service

You can integrate a Model repository with a version control system that you use in your organization. A version control system protects Model repository objects from overwriting objects on a team where multiple developers work on the same projects. A Model repository can use only one version control system instance. You can integrate the Model repository with the Perforce, Subversion, or Git version control system.
A version control system allows one user at a time to check out, edit, and save an object. When you save an object, the object is saved in the Model repository. After you check in the object, a version is created in the version control system. The version control system maintains a history of all the versions. You can edit only the latest version of the object. You can view the other versions of the object in read-only mode. You can roll back to a previous version or reassign the checked-out state of objects to another user. A version control system protects a Model repository object from unwanted updates because it does not allow multiple users to edit an object at once.
Perforce and Subversion are centralized version control systems. You might lose data if the Perforce or Subversion version control system server is not accessible or the server unexpectedly shuts down.
Git is a distributed version control system. When you check in an object, the Git version control system checks in the object. It saves a copy in the remote Git repository and local Git repository. If the remote Git repository is inaccessible or if it shuts down unexpectedly, you can access the local Git repository to view all the versions and edit the latest version of the object.
When you choose the Git version control system, you can configure the following components:
Remote Git repository
You need access to the remote repository on the Git server. To configure the version control system, you need the URL, user name, and password of the remote repository. You can use HTTP or HTTPS protocol to access the remote Git repository.
Local Git repository
Create a directory on the machine that hosts the Model Repository Service to serve as the local Git repository.
The directory must meet the following requirements:
When the Model repository is integrated with a version control system, you can check in revised objects, undo the checkout of objects, and reassign the checked-out state of objects to another user.
Note: If the Model repository is integrated with a version control system, you cannot use the Model repository for mass ingestion.

Configure and Synchronize a Model Repository After Changing Versioning Properties

You can enable version control, configure versioning properties, and then synchronize the Model repository with the version control system. After you configure versioning and synchronize the Model repository with the version control system, the version control system begins to save version history.
The following image shows the process of configuring, synchronizing, and re-synchronizing the Model repository with a version control system: The image shows the flowchart to configure and synchronize the Model reposiotry after changing versioning properties.
  1. 1. Configure the versioning properties and recycle the Model Repository Service.
  2. 2. Synchronize the Model repository content with the version control system.
  3. 3. Optionally, change the version control system type.
    1. a. For Perforce, you can change the host, port number, username, or password.
    2. b. For SVN, you can change the URL, port number, username, or password.
    3. c. For Git, you can change the file path of the local Git repository, URL of the remote Git repository, username, or password.
      4. After you change the versioning properties, you can choose to retain or discard the version control history:
      1. a. Retain version control history. Copy content from local repository to new local repository.
      2. b. Discard version control history.
  4. 4. Recycle the Model Repository Service
  5. 5. Re-synchronize the Model repository content with the version control system.
You can perform these tasks from the command line or from the Administrator tool.
Note: When you change Model repository properties, you must recycle the Model Repository Service for your changes to take effect. When you enable version control system or change a versioning property, the Model repository remains unavailable until you synchronise the Model repository.

Synchronizing the Model Repository with a Version Control System

Before you synchronize the Model repository with the version control system, you configure versioning properties, and then recycle the Model Repository Service for property changes to take effect. Then synchronize the contents of the Model repository with the version control system.
Note: While synchronization is in progress, the Model repository remains unavailable.
    1. Instruct Model repository users to save changes to and close repository objects.
    2. On the Manage tab, select the Services and Nodes view.
    3. Select the Model repository to synchronize with the version control system.
    4. Click Actions > Synchronize With Version Control System.
    5. Click OK.
    The Model Repository Service copies the contents of the repository to the version control system directory. During synchronization, the Model repository is unavailable.
When synchronization is complete, versioning is active for Model repository objects. All Model repository objects are checked in to the version control system. Users can check out, check in, view version history, and retrieve historical versions of objects.
After the Model repository is synchronized with the version control system, you cannot disable version control system integration.

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.
The operation to synchronize the Model repository with the version control system fails.
When you attempt to synchronize the Model repository with the version control system, the operation fails with an error message from the version control system. For example, you might see an error like:
The Repository Service operation failed.
['[RSVCSHARED_01524] Unable to submit changes to the version control system.
Encountered the following error: '4'.']
To address this problem, check that the code page settings for the Model repository and the version control system are compatible, depending on your locale.