Studio Commits

Overview

Modified items are sent back to the Repository via *Commits.*A commit is a bundle of one or more modified items that as one unit are sent to the repository to create new versions of the items included in the Commit. The commit is treated as one transaction: Either all new versions are committed successfully or none at all.

Some advice on good Commits:

• Keep commits small. Large commits are difficult to understand and describe.
• Make a commit a consistent change. If, for instance, you add a new Condition Rule and use the new rule on a Target Object, commit the new rule and the modified Target Object together.
• Strive to leave the project consistent with each commit. In the example above, avoid committing the new version of the Target Object without committing the new rule as this would leave the project inconsistent.

Pending Changes

The Pending Changes tool window lives on the left edge of the Studio window (unless, of course, you undock it and move it to somewhere else). Hover the mouse over the Pending Changes tab to expand the tool window:

Use the checkboxes in the treeview to compose the commit, write a good commit message and click the Commit button to send the commit off to the Repository.

Commit Messages

A commit is accompanied by a message to describe the change that is being committed. Good commit messages are essential and should be required for all commits. Indeed, the default setting in the Repository Manager is to require messages on all commits. While it is possible to change this policy to make commit messages optional, it is highly recommended to refrain from doing so. Looking at the version history of a given item is, after all, vastly more meaningful if each version has a descriptive message.

The commit message should be to the point and accurately describe the commit. It is good practice to use imperative statements to signify what the commit does: Write 'Add account business object' rather than 'Added account business object'.

Item Deletion

Deleting an item is a 2-step process:

1. At first, deleting the item marks it as deleted in Studio and also checks out the item for deletion. It follows that it is not possible to delete an item that is checkout to somebody else.
2. When you commit, the item is deleted from you workspace and from Studio and the deletion is committed to the Repository.

Deleting an Item

Current User	Other Users
Has deleted Valueset AccountProducts Studio has placed a Delete Lock on the item in the Repository An Undo Checkout would remove the lock	The Valueset AccountProducts is checked out to somebody else
Has committed the deletion Studio has deleted the item in the local workspace Studio has removed the delete lock in the Repository Studio has added a new, delete-marked version to the Repository	The Valueset is now marked as deleted in the Repository A Get Latest Version on the Valuesets folder will delete the Valueset from the local workspace

Deleting a Child Item in the Target Map

In the Target Map, parent items contain references to all their child items. In order to delete a child item, the parent item must be checked out:

Current User	Other Users
Has checked out the Business Object Customer Studio has placed a lock on Business Object Customer in the Repository	Business Object Customer is checked out to somebody else
Has deleted child Business Object Individual (including Target Object Tgt.IP_Individual) but not yet saved Business Object Customer Studio has removed child Business Object Individual but will restore it if the user closes Customer without saving changes	No change to visual cues in Studio
Has now saved Business Object Customer Studio has placed a Delete Lock on all descendant items The delete locks are not visible for this user but will be removed if the user performs an Undo Checkout	The Delete Lock appears on descendants Individual and Tgt.IP_Individual
Has committed the changes to Business Object Customer Studio has removed the locks in the Repository Studio has created a new version in the Repository for Customer without the reference to the Individual child Business Object Studio has created a new delete-marked version for each of the two deleted descendants: Individual and Tgt.IP_Indivudual User A has completed the modification	Since a newer version of Business Object Customer exists in the Repository, the local version is now marked as Stale The two descendants Individual and Tgt.IP_Indivudual are marked as deleted in the Repository A Get Latest Version on Business Object Customer retrieves the latest version and deletes the two descendants locally The other user has now received the updated change from the Repository

Deletion Commits

When an item is deleted, the commit of the deleted item simply creates a new version of the item. This new version is marked as deleted.

The figure above illustrates three commits:

Commit 1	Adds Item A Modifies Item C
Commit 2	Modifies Item A Modifies Item C again
Commit 3	Modifies Item A again Modifies Item B again Deletes Item C

Reverting a Commit

It is possible to revert a commit. This means that Studio will inspect the commit to be reverted, and for each item in the commit, find the version that was previous to the commit being reverted. Studio will then create a new commit to create new versions of the items equal to the previous versions. If the commit being reverted added an item, the new commit will create a delete-marked version for this item.

Commit 1	Add Item 1 Modifies Item 2 (version 2) Deletes Item 3
Commit 2 (reverts Commit 1)	Deletes Item 1 Restores Item 2 to version 1 by creating a new version 3 identical to version 1 Restores deleted Item 3 by creating a new version 5 identical to version 3

Use the checkboxes in the treeview to compose the commit, write a good commit message and click the Commit button to send the commit off to the Repository.