Compare

Diff two versions of a model down to the property and the line of DAX, then cherry-pick exactly the changes you want into the model you have open. Compare works against a git ref, a file on disk, or another live model, so it fits dev-versus-prod drift checks and hotfix porting alike.

#In the Studio

The Compare tab shows an object-level diff in one view with three modes that share a single Source and Target and a single selection. Review is a pull-request-style list, grouped by table then kind, where you tick the objects to bring across. Side by side is a two-column, word-level comparison of the before and after. Map lays the tables out as blocks sized by object count and tinted by how much changed, so a big divergence is obvious at a glance. An "Only differences" toggle hides everything that matches, and you can drill from any object down to the specific property and the exact code that changed.

Compare a local model against a published one and the diff shows only what actually differs: the runtime bookkeeping a server adds (last-processed and last-modified stamps, refresh state) is normalised away before the comparison, so a clean model reads as clean instead of every object showing as changed. A native status-bar item mirrors the same "editing versus querying" verdict while you work outside the Studio, and clicking it opens a seeded compare.

Pick a comparison target: the last commit, a branch or tag, a model file, or another model you have open. Then cherry-pick a merge, select the objects you want and bring just those across.

#Over MCP

The diff and merge primitives are dual-drive:

• model_diff is the semantic compare. By default it compares the open model against the git ref HEAD (what you changed since the last commit); pass a different git ref to compare against a branch or commit, a target file to compare against a model on disk, or two files to compare each other. It returns the per-object Create/Update/Delete with before/after text, and it is read-only.
• cherry_pick copies objects from another model into the open one (a teammate's measure into yours, say). It is a dry run by default (it reports what would copy, what already exists, and what cannot), and commit=true applies it as one undoable batch. It handles measures, calculated columns and calculation items into an existing group.
• apply_model_diff goes the other way: it merges the open model's changes into a target, making the target match the open model for the objects you choose. The target is a model file on disk, or a published model on an XMLA endpoint (the selective push, drift-guarded with a restore point written first, see Deploy). It is dry-run by default, with commit=true to write, selectedRefs to limit the scope, and overrideReason as the accountable way through a drift refusal.
• Multi-model sessions are first-class: open_model opens another model and create_model starts a new one from scratch, so you can hold both sides at once.

model_diff                                  # open model vs HEAD (uncommitted changes)
model_diff  gitRef=origin/prod              # dev vs prod drift
cherry_pick sourceFile=<prod.bim>  refs=["measure:Sales/Margin %"]              # dry run
cherry_pick sourceFile=<prod.bim>  refs=["measure:Sales/Margin %"]  commit=true # apply

#Two everyday jobs

• Dev versus prod drift. model_diff against the production git ref (or a live endpoint) shows exactly which objects diverged, before anyone deploys.
• Hotfix porting. Fixed a measure in one branch and need it in another? cherry_pick brings just that measure across, dry-run first so you see whether it would overwrite anything, then committed as one undoable step.