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.

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"/> 
```

Set the AtomicBehavior setting value to 1.

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

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.