Version History & Comparison

Every module keeps a complete, browsable timeline of its commits. The Version Control browser is where you read that timeline: it shows who committed what and when, lets you look at exactly what changed in any commit, compare any two points in the module's life, restore an earlier state, and audit the whole evolution of a design for regulatory traceability.

Related: 🌿 Commits and Branches · 🔀 Merging · 🗂️ Version Control

🔍 Opening the Version Control Browser

The browser is always one click away while a module is open. You can reach it two ways:

📊 The Version Control Window

The window is split into two parts. On the left is the History timeline — one row per commit, newest at the top. Each row shows:

• A coloured author chip with the committer's initials, so you can scan at a glance who did what.

• The commit description you (or a colleague) wrote at the time.

• A subtitle with the author name and a relative time ("3 days ago").

• A small change summary pill reading +A ~M −R — how many records were added, modified, and removed compared to the commit before it.

On the right is the changes panel, which fills in when you select a commit or run a comparison. It lists every change as an easy-to-read card (see Reading the Changes below).

📋 Viewing What Changed in a Commit

To see what a single commit introduced, select it in the History list — the changes panel immediately shows everything that commit changed compared to the one before it. You can also right-click a commit and choose View changes (vs parent) for the same result.

This answers the everyday question "what did this checkpoint actually do?" — for example, selecting the commit "Checkpoint v1.2 — Caustic wash tuned" might show that the NaOH dosing concentration on the Caustic Wash step changed and that valve CV-202 gained a new state.

🔄 Comparing Any Two Versions

Comparison lets you see the difference between any two points in the module's life — not just neighbouring commits.

1. Select the first commit in the History list.

2. Click Compare… on the toolbar (or right-click a commit and choose Compare with…, which pre-selects it).

3. Pick the second commit to compare against.

4. The changes panel shows every difference between the two, each as a change card.

This is the tool for questions like "what changed between the Conceptual Baseline and the Detailed Engineering checkpoint?" — useful when preparing a change summary for a design review or a regulatory submission.

📖 Reading the Changes

Every change is shown as a changelog card written in the language of your process design, not in raw database terms. Each card carries a type badge and the human-readable detail of the change:

Values are rendered the same way you see them everywhere else in AseptSoft: a state shows its colour bullet, a valve shows its tag and PID, a percentage shows a gradient bar, a fluid response resolves to the fluid's name, and version numbers read naturally ("the version went 1.1 → 1.2"). References between records read as named chips — for example "this valve is administrated by that block valve", or "this slot maps to PIT-101" — so you never have to decode an internal identifier.

🔍 Filtering and Grouping a Large Diff

A busy checkpoint can touch hundreds of records. A filter bar above the changes keeps it navigable:

A live "N of M" count tells you how much the current filter is showing. When you group by PID or Process, AseptSoft places each change under the section it truly belongs to — a valve state appears under its valve's PID, an instrument's control relation appears under that instrument's PID — even though the change itself is several steps removed from the PID. Process-, phase-, and condition-level changes that don't belong to any single PID fall under a trailing "Not PID-specific" group.

📋 Copying Changes Out

Use the Copy button above the changes to take a snapshot of the shown changes to your clipboard. A normal click copies a clean, human-readable summary — ideal for pasting into a change-control record, an email, or a review note. A right-click copies the underlying raw data instead, for the rare case where you need the exact stored values.

⏪ Restoring an Earlier Version

Restoring brings a past commit back to life — safely. AseptSoft never overwrites your working module or rewrites history. Instead, a restore creates a brand-new module from the snapshot, leaving the original and its full timeline untouched.

📖 How To: Restore a Commit as a New Module

1. Select the commit you want to bring back in the History list.

2. Click Restore as new module… on the toolbar (or right-click the commit and choose the same).

3. Enter a name for the new module.

4. The restored module appears in the module gallery immediately — no need to reopen the project.

✏️ Managing Commits

Right-clicking a commit in the History list opens a menu of per-commit actions:

🏭 Pharma Example: Auditing a CIP Module for a Design Review

You're preparing a CIP Rinse Cycle module for a peer review and need to show how the design evolved since the last approved baseline.

1. Open the module and launch Version Control from the Data split button.

2. In the History timeline, find the "Conceptual Baseline" commit and the latest "Detailed Engineering" checkpoint.

3. Select the baseline, click Compare…, and pick the detailed-engineering checkpoint.

4. Group the changes by Process to see, process by process, what moved — the Pre-Rinse, Caustic Wash, Final Rinse, and Drain steps each in their own section.

5. Filter to Modified to focus on tuned values — for instance the NaOH concentration and the WFI rinse duration.

6. Click Copy to drop a readable change summary into your review document.

The result is a complete, named, time-stamped account of every meaningful change — exactly what a regulated environment needs for traceability.

🔗 Related Pages

• Version Control — Parent section.

• Commits and Branches — Creating commits and organizing branches and modules.

• Merging — Bringing changes in from another source and resolving conflicts.

• Review Sessions — Collaborative validation workflow.

• File System — Where version control data is stored on disk.