How to compare two PCB revisions

Why the file diff does not help

A KiCad schematic or layout is a text file, so git will happily diff two revisions. Moving one resistor rewrites its coordinates, its identifier and the wires that touch it, and a real change is buried in hundreds of lines that mean nothing at a glance. An Altium document is binary, so the diff is not even that: it is a note that the file changed. Either way the reviewer ends up opening both revisions side by side and eyeballing them, which is the method this page replaces.

Compare on BoardRepo

Open the board, open Version history, and choose Compare versions. Pick the From and To versions; any two published versions work, not just neighbours. Comparing needs a signed-in account, which viewing the board does not, because the comparison is computed on request from both versions' files.

The result is the board you already know, drawn twice and dimmed, with the changes painted on top so the render is context and the highlight is signal. The same is done for the schematic. Beside the drawings is a list of every change by name, grouped as Parts (a component added, removed, moved, rotated, flipped, renamed, or given a new value or footprint), Routing (tracks, vias, and zones and their fills), Board (outline size and layer stackup) and Other. Selecting a change in the list highlights it on the board, and clicking a highlight selects its row.

What it needs from the two versions

Both sides must have been rendered, which happens when a version is published; a version that failed to render says so in its pane rather than showing an empty frame that reads as “nothing changed”. Both sides must be the same kind of design: a KiCad version and an Altium version of the same board cannot be compared to each other, and two Altium versions compare once both have been converted by the same converter generation. When a pair cannot be compared, the page says which of these is the reason instead of guessing.

The comparison is built from the renders BoardRepo already has for each version, so it costs nothing to run and nothing to keep. It is not a replacement for design-rule checks: a change that passes compare can still fail DRC, and the checks are the place to catch that.

Using it in a review

The habit that makes this useful is to version at review boundaries: publish the revision you want reviewed, send the board link, and ask the reviewer to compare it against the last version they approved. They read the change list first, then look only at the highlighted areas. A board with three highlighted parts and one moved via is a five-minute review; the same board as two zips is an afternoon.

If the review turns up a mistake, restore the earlier version as the latest from the same Version history dialog. The restore is a new version, so the mistaken revision stays in the history and can itself be compared against later.

Find a board with several versions to try it, or read about version control for PCB designs.