Committing and Optimizing a View Compare/Merge Change Session

This topic describes how to commit and optimize a View Compare/Merge change session.

Committing a View Compare/Merge Change Session

Committing a View Compare/Merge change package session applies all changes to the StarTeam repository. You must resolve all merge conflicts before you can commit the View Compare/Merge change session.

To commit a VCM session, do the following:

  1. Open the target view in the Cross-Platform Client Content Perspective containing the change session you want to commit.
  2. Double-click the change package you want to commit. It will be listed in the list of change packages in the Content Perspective and will have a status of New.

    Note: If you do not see the session you want, make sure the Filter list has the correct selection so all sessions are displayed.

  3. Double-click the change package session to open it in the session.
  4. Verify that you have resolved all merge conflicts in the Compare Perspective and the Merge Perspective of a change session, and that you have tested your changes to make sure they give the expected results. When the changes in a change session are complete, it can be committed.
  5. Choose VCM Session > Commit Changes.

    Note: If Commit is disabled on the menu or toolbar, check the Compare and Merge Perspectives to make sure all conflicts are resolved, and items with changes are not locked by other users, then try again.

  6. Type a merge session comment in the Commit Changes to View dialog box.

  7. Click OK in the Commit Changes to View dialog box to commit your View Compare/Merge session.

    This causes its updates to be applied to the target view in an atomic transaction. In the same transaction, the change package object is updated with details about updated items. After commit, the change session is closed and can no longer be opened for editing. In its place, the committed change package appears as an object owned by the target view, and can be viewed again in the Change Perspective.

  8. Save your change session using VCM Session > Save, VCM Session > Save to Local, or VCM Session > Export.

    Note: Save saves the session persistently, minimizing the need to save the session as a file. Save to Local saves the session as a .vcms file, and Export saves the session as a .vcmx file.

StarTeam creates a uniquely named change package object in the target view for the change session which contains all the changes made in that VCM change session. It then becomes available in the Change Perspective, where it can later be opened in read-only view, reviewed, have the properties modified, or have the session Replayed which allows you to reuse the change package session to apply the same set of changes to another view. Once a change package is committed, no more changes can be made to it.

Back to top

View Compare/Merge Optimization

View Compare/Merge optimization is a workaround for very large View Compare/Merge commits (that is, tens of thousands of View Compare/Merge operations), which cannot realistically succeed when run in a server and database transaction.

To use this workaround, the session must be committed by a user who has the Modify system configuration Server Access Rights granted and is preferably using the 64-bit SDK or StarTeam Cross-Platform Client. The session should also be run when there is little to no other activity on the StarTeam Server, because of the extensive resource allocation to be provided for this commit session.

  1. Turn on the setting AtomicBehavior in the starteam-server-configs.xml file. There is no need to stop and restart the server just to change this setting.

    The default value of this setting is 0, meaning that Atomic Transactions are enabled by default. 

    <option name="AtomicBehavior" value="0"/>

  2. Set the AtomicBehavior setting value to 1. 

    <option name="AtomicBehavior" value="1"/>

  3. Wait for a minute, then run the large View Compare/Merge commit from a 64-bit version of the SDK or StarTeam Cross-Platform Client using the Administrative Context with privileges to modify server settings.

    Note: Running the session from a 32-bit SDK or StarTeam Cross-Platform Client runs the risk of the StarTeam Cross-Platform Client running out of memory before the session is committed.

When the session starts up and discovers that AtomicBehavior is disabled, it will immediately re-enable it and then run the session without transactions. This means that a subsequent sessions will automatically run with transactions enabled.

If the session is run using non-administrative privileges, then the attempt to re-enable transactions in the server will fail, and the setting will be ignored. In this case, the session will run with multi-command transactions enabled, as if the settings were unchanged.

Internal testing has indicated that a session with 65,000 files being reverse-shared run in 2 hours on a single machine and 5 hours across a network with this new workaround. Without the workaround (that is, with transactions enabled), the same commit takes over 24 hours and does not complete.

Back to top