1. Database Upgrade Guide
  2. RepositoryUpdate Utility

RepositoryUpdate Utility

The RepositoryUpdate utility delivers optional Repository changes made by the Oracle Siebel CRM development team since Siebel CRM 17.0. The RepositoryUpdate.zip file, located in the siebsrvr\binfolder, contains the payload forRepositoryUpdate. If interested, customers may unzip the file to see its contents – a subfolder will exist for each release that has changes (for example: 20.3, 20.7, 20.8, 21.12, 22.1, 24.8, 25.12, and so on).

The RepositoryUpdate utility inspects the database table S_WS_VERSION to determine the last time it ran and the next release from which to start running updates.

During execution, the RepositoryUpdate utility imports data from the releases added since the last time it was run. This prevents customers having to re-resolve any conflicts they have already addressed.

As an example, if there is a ten-release gap between the previous and current versions of the Repository, there will be ten folders for RepositoryUpdate to process. The incremental changes from each release will be processed in order, but only a single Integration Workspace will be created. This ensures that if Object “X” changed in 24.1 and again in 25.12, then the combined changes will be merged so that customers get only the latest version.

Assuming it is January 2026, the typical order of events to follow when planning to run the RepositoryUpdate utility are:

  1. Customer identifies a feature that they want that is provided in a particular Monthly Update (25.11, for example), which requires Repository changes
  2. Assuming that the customer performs monthly internal releases, the customer analyzes the effort involved in consuming the changes (merge with existing customizations, test, and so on) and picks a future release when they plan to actually deploy it (in February 2026, for example).
  3. Customer runs the RepositoryUpdate utility, pointing to their February 2026 release Integration Workspace Branch, where they are staging their changes to be released in February. This keeps all the changes out of the current MAIN Workspace and any other release planned before February.
    1. Creates a child Integration Workspace named int_siebel_updateN (where N is a sequential number that one more that then previously imported RepositoryUpdate payload).
    2. Creates a child Developer Workspace under int_siebel_updateN where all changes are imported – this is done because you cannot directly edit an Integration Workspace, so by putting it into a Developer Workspace, it allows us to make edits before we deliver it to the Integration Workspace.

      You must review the Developer Workspace to determine what objects have changed and resolve any conflictsbefore delivering it to the parent int_siebel_updateN branch. See the UsingSiebel Tools guide for more information about this process.

  4. Once the customer is confident that the changes provided by Oracle and the changes that they have made are compatible, the customerdelivers int_siebel_updateN to its parent branch (in this example, their February IWS).

    It is possible that a Rebase will be required and the customer will have to resolve conflicts before delivery.

  5. After delivery, the February 2026 branch we have been discussing will contain the latest (Oracle and customer) changes and can be migrated to test environments as needed.