Drift and Merging

You are not the only person who can change a rule. Somebody can open the same rule in Calculation Manager and edit it there while your copy sits in VS Code. Before EPM Workbench writes anything to your Pod, it checks whether that happened.

That check is the Drift Check, and it runs at the start of every Push, Deploy, and Execute. When it finds something that moved, the action stops before it uploads and opens a review tab so you decide what happens to each artifact.

Sync badges

Rule, Script, and Template rows in the Rules tree carry a one-letter badge when your copy and the Pod’s copy have diverged. Hovering the badge shows the same wording:

Badge	Tooltip	What it means
A	Ahead - Local Changes Not In Calc Manager	You edited the Body. Calc Manager still has the version you last synced. This is the normal state before a Push.
B	Behind - Changes in Calc Manager Not Local	Somebody changed the rule in Calc Manager and you did not touch your copy.
!	Drift - Changes in Both, Need to Merge	Both sides changed. This is the case that needs a real decision.
U	Untracked - Never Synced With Calc Manager	The file has no sync record yet, usually because you created, renamed, or copied it and have not Pushed it.

A row with no badge matches the last state EPM Workbench recorded for it.

Badges update on their own from two directions. Your own edits show up as soon as you save the file, so A appears the moment you save. The Pod’s side is refreshed whenever EPM Workbench looks at the Pod: a Pull, or the Drift Check that starts every Push, Deploy, and Execute. That is why B and ! can appear on rules you have not opened all day.

Library Folders show no badges. A Library is not connected to a Pod, so there is nothing to compare against. See Library Folders.

The Drift Check

Drift Check is the first Step of every Push, Deploy, and Execute, and it shows up as that Step in the Runs Panel. It reads what Calculation Manager holds right now for the artifacts you are acting on and compares it against what EPM Workbench last recorded.

• If nothing moved, the Step passes in a couple of seconds and the action carries on with no interaction at all. The Step says how many artifacts it checked.
• If something moved, the Run pauses at the Step and the review tab opens. Nothing has been uploaded at that point, and nothing will be until you decide.

What gets checked depends on the action:

Action	Checked
Push	The artifacts you are Pushing.
Deploy	Those artifacts plus every %Template and %Script they pull in.
Execute	The same as Deploy, because Execute deploys first.

Deploy and Execute cast the wider net because they expand macros from your local content. A Rule that is perfectly in sync can still deploy a Script that somebody else has rewritten, so the Script gets its own row in the review, marked (dependency).

The Drift Check also refreshes the Last checked line in the EPM Details panel for the artifacts it looked at.

If the check finds drift and there is no way to review it, nothing is uploaded and the Run stops. That is deliberate: an unanswered question is never answered by overwriting somebody.

The review tab

The tab is titled Review Push, Review Deploy, or Review Execute with the number of artifacts, and it lists one row per artifact that moved. Each row shows the artifact name, its status, when Calc Manager was last modified, and who modified it, when Oracle reports those.

If the tab opens behind what you were doing, a notification points at it: Push found 2 artifacts changed in Calc Manager since your last sync. with Review and Cancel. Pull’s equivalent reads Pull is awaiting review of 2 locally modified Bodies. with Review Pull and Cancel Pull.

Row statuses read in plain words:

Status	Meaning
Changed in Calc Manager	Only their side moved.
Changed on both sides	True drift. This is the row the Merge button is for.
Exists in Calc Manager (never pulled)	You have an artifact by that name, EPM has a different one, and the two have never been linked.

Compare opens VS Code’s normal diff view with your Body on the left and Calc Manager’s on the right, so you can see what actually changed before choosing.

Each row then gets a resolution:

Resolution	What it does
Update local & continue	Takes Calc Manager’s content into your file and carries on with the now-identical content. Your file is backed up first.
Take Calc Manager’s version	The same adoption for a drifted row: their content wins and yours is backed up.
Overwrite Calc Manager	Ships your local content anyway. Never the preselected choice.
Push anyway	The same thing for an artifact that was never linked.
Skip	Drops the artifact from this Run and leaves both copies alone. On a (dependency) row it means “keep my local macro”: the Deploy or Execute carries on and expands your local content.

The footer says how many artifacts are in the list, and offers Cancel Push (or Deploy, or Execute) and Apply & Continue. As the tab itself puts it: nothing is sent to Calc Manager until you Apply. Cancelling, or closing the tab, cancels the Run.

Merging

A row marked Changed on both sides has a Merge… button. Merging combines their changes with yours instead of picking a winner.

1. Click Merge…. Your rule file opens with the merged result already in it, written into the editor buffer. The file on disk is untouched until you save.
2. Everything the merge could work out on its own is already applied. What it could not is left as a conflict block, marked <<<<<<< Local for your side, ||||||| Base (last sync) for the content both sides started from, and >>>>>>> Calc Manager for theirs.
3. Resolve each block with VS Code’s built-in merge conflict actions above it: Accept Current Change keeps your version, Accept Incoming Change takes Calc Manager’s, Accept Both Changes keeps them in order, and Compare Changes shows the two side by side.
4. Save the file. That is what completes the merge, and only a save with no markers left counts. Saving with a conflict block still in the file does nothing to the review.
5. The row in the review tab flips to Merged — will ship, its resolution dropdown is replaced, and the Merge button becomes Re-merge. Click Apply & Continue and the merged file is what gets Pushed.

Changed your mind about a merge you already completed? Click Re-merge to start over from the last synced content. If you leave the review without completing a merge, your file goes back to exactly what it was before you clicked Merge…, on disk as well as in the editor.

Tip

Turn on VS Code’s merge-conflict.autoNavigateNextConflict.enabled setting and resolving one block jumps you straight to the next.

Whitespace-only changes keep your spelling

Your rule files are formatted by EPM Workbench on save; the copy in Calculation Manager is not. If the merge compared them as-is, every line would look changed and the real edits would be buried. So before merging, EPM Workbench reads the Calc Manager content in your file’s whitespace style, matching lines that are identical apart from spacing.

The trade-off: a change that is only whitespace, including inside a string literal, is treated as no change at all, and your file keeps its own spelling of that line. Everything else merges normally. Compare always shows Calc Manager’s raw content, so you can see the difference the merge chose to ignore.

If Merge is unavailable

Merging needs the content you last synced as a common starting point. If EPM Workbench does not have it, the Merge… button is disabled and the tooltip says so. Use Compare and resolve by hand, or pick one side. That copy of the last synced content lives in .epmwb/cache/baselines/ inside your Pod Folder. It is excluded from git and safe to delete at any time: deleting it costs you merges until the next Pull or Push, and never affects sync correctness.

Merging during a Pull

Pull has its own review, and it appears for a different reason: Pull would replace Bodies you have edited locally. Rows where only you moved are the ordinary case. Rows where the Pod moved too are marked as drift and carry the same Merge… button, with the same buffer-and-save flow.

Artifacts that are only Behind never reach this review. Bringing them down is what Pull is for, so they are simply updated.

Once at least one row is merged and saved, the footer changes. Merged rows pin with a green resolved badge and their checkbox is disabled, because a merged file is never a candidate for being overwritten. Re-merge on the row is the way to change course. The buttons become:

Button	What it does
Complete Merge	Every row was merged. Finish.
Complete & Skip Rest	Keep every remaining local Body unchanged.
Complete & Overwrite Rest	Replace every remaining local Body with the Calc Manager content.
Complete & Overwrite Selected	Replace only the rows you checked.

The follow-up dropdown

Next to those buttons is a dropdown for what happens to the merged artifacts once the review closes:

• Do Not Push Updates leaves them in your folder.
• Push Updates to EPM writes them into Calculation Manager right away.
• Deploy Updates to EPM goes one step further and deploys them.

Choosing Push or Deploy here is the confirmation, so you are not asked a second time. The chained action still runs its own Drift Check, which is what catches a colleague who edited the same rule again while you were merging.

Tick Remember my selection and your choice becomes the epmWorkbench.afterMergeAction setting, which is where the dropdown starts from next time. The setting and the checkbox are the same thing, so you can change it later in Settings.

After a merge

A merged file has content that exists nowhere else yet, so it is honestly Ahead until it lands in Calculation Manager. Push it, or use the follow-up dropdown to do it in one gesture.

Two things carry over from the Pod’s copy so nobody’s work is quietly reverted:

• Metadata a colleague edited in Calculation Manager, such as the description, is kept and travels back with your merged Body.
• Run-Time Prompts you defined locally survive too, because they live in your Pod Folder’s RTP model and are rebuilt on the way out. See Run-Time Prompts.

If both sides edited the same Run-Time Prompt definition, your local definition wins. There is no automatic merge for that case yet.