Merging

Merging brings changes from any other module, template, or commit into your current module. AseptSoft uses a three-way merge that compares the source, the destination, and their last common ancestor to apply non-conflicting changes automatically and surface only the genuine conflicts for you to decide. Conflicts are presented in a visual, side-by-side review built from the same domain language you use everywhere else in AseptSoft.

Related: 🌿 Commits and Branches · 🕑 Version History & Comparison · 📁 File System · 🗂️ Version Control

📥 Pull Changes Workflow

To merge changes into the active module:

1. Open the merge dialog — select Update from… in the module's context menu.

2. Select the data source. Refer to the File System to locate your source.

3. Review and resolve conflicts in the merge review window (most are resolved for you automatically).

4. Press Commit to apply the merge.

5. Review the Changes tab — every difference between the two versions is listed for a final check.

🧮 Three-Way Merge Algorithm

AseptSoft compares three snapshots — source (incoming), destination (current), and parent (last common ancestor) — to decide the correct action for every entity:

Note: Bookkeeping properties — date edited, date created, author, and graph-visualization position — are untracked and never trigger conflicts. Each workstation also keeps its own per-module settings: settings are never merged, shown, or conflicted on.

✅ Conflicts Resolved Automatically

Most differences are not real disagreements, and AseptSoft resolves them for you so you only spend attention on the genuine decisions. The following are settled automatically and are not shown as conflicts:

🤝 Reviewing & Resolving Conflicts

When real conflicts remain, the merge review window opens. It is built to mirror how you already think about your design — Process → Step → Condition, a valve in a PID with a coloured state, a setting with a category — rather than raw database rows.

🖱️ The Conflict Card

Each conflict is a compact card that leads with only the fields that actually differ. The two sides are shown as selectable panels:

• Incoming — the value from the source you're pulling from.

• Current — the value in your module right now.

• When a common ancestor exists, a neutral BASE column shows what each field started as — a true three-way view of where the two sides diverged from.

To resolve a card, simply click the side you want to keep — anywhere on that panel. Values render richly inside the card: state colour bullets, valve and instrument chips with their PID, percent gradient bars, fluid names, and named references — so the choice reads in plain terms. A "Full record" toggle expands the card to show every field of both sides when you need the complete picture; otherwise the card stays small and focused.

🔍 Grouping, Filtering & Ordering Many Conflicts

A side rail keeps a large set of conflicts organized. You can switch how conflicts are grouped and narrow the list:

Each group shows a count of how many of its conflicts are resolved. Auto-resolved conflicts are hidden from the list by default, so the rail counts reflect what genuinely needs your attention.

🔢 Reordering Steps and Processes

When you and a colleague reorder the same sequence differently — for example you reorder a CIP process to Pre-Rinse · Final Rinse · Caustic Wash while a colleague reorders it to Caustic Wash · Pre-Rinse · Final Rinse — AseptSoft does not ask you to resolve each step's position one by one (which could leave two steps fighting over the same slot). Instead it shows a single Order conflict for the whole sequence, with the incoming order, the current order, and the original order side by side, and one final-order list you arrange directly:

• Drag items into the order you want (or use the up/down arrows).

• Use Use incoming or Use current to adopt one side wholesale as a starting point.

After the merge, the sequence is repacked into a clean, gap-free order. This applies to process order, step order within a process, condition order within a step, and equipment-module step order.

📋 Copying Conflicts Out

Every conflict card has a small copy button, and a Copy all button copies every shown conflict at once. A normal click copies a clean, human-readable summary — title, scope, reason, and each differing field's incoming and current values in the same readable form the card shows. A right-click copies the underlying raw data instead.

⚠️ Conflict Types

Genuine conflicts fall into two families:

🔁 Duplicate ID Conflicts

The same entity exists in both source and destination but was changed differently from the common parent — for example a Process renamed to "CIP" in one and "SIP" in the other.

🔑 Unique Property Conflicts

Applying all changes would break a uniqueness rule. AseptSoft enforces these constraints:

🔗 Keeping References Intact

When you resolve a conflict by choosing one side, every cross-reference throughout the module is updated to stay consistent — including identifiers embedded inside text (such as fluid-response expressions). After applying your choices, AseptSoft re-checks for any new conflict the change might have introduced and resolves the set iteratively until everything is consistent, then commits. Your recorded decisions are matched to each conflict by identity, so they hold even as the merge re-evaluates — the choice you made is the choice that's applied.

🏭 Pharma Example: Merging a CIP Optimization Branch into Main

The lead engineer maintains the baseline CIP (Clean-in-Place) process on the main branch, while a process optimization engineer worked on a "CIP Optimization" branch (see Commits and Branches) to reduce water consumption. The optimization has been approved in a Review Session and is ready to merge back.

📖 How To: Merge an Optimization Branch into Main

1. Switch to the main branch and open the module that should receive the optimized process.

2. Right-click the module → Update from…

3. Select the source — navigate to the "CIP Optimization" branch and pick the corresponding module.

4. Let AseptSoft auto-resolve the identical, additive and knock-on differences, then review what remains.

5. Resolve the real conflicts — for instance, the lead renamed the pre-rinse step to "Initial Rinse" while the optimization engineer renamed it to "Water Recovery Rinse". Click the side you want directly on the card; for a valve such as XV-101 that both touched, choose Keep both to retain both configurations.

6. Reconcile the step order if both sides reordered the cycle — arrange the single final-order list to the sequence you want.

7. Press Commit to finalize, then check the Changes tab to confirm exactly what landed.

📊 The Changes Tab

Alongside the conflicts, the merge window's Changes tab shows every difference between the two versions — added, changed, and removed records — rendered as the same readable cards used in version comparison. Outdated records whose owner no longer exists are filtered out so the list stays meaningful, and you can copy the whole list (readable or raw) for a change record.

🔄 PID Migration

A specialized merge variant migrates an entire PID (Process & Instrumentation Diagram) from one module into another:

1. Preflight check — detects potential collisions before starting: valve and block-valve shape clashes, and Review Session name clashes.

2. Conflict resolution — resolve any detected collisions using the P&ID strategies (Keep both, Keep incoming, or Keep current).

3. Entity migration — every entity owned by the source PID is transferred, with all ownership references updated automatically.

🔗 Related Pages

• Version Control — Parent section.

• Commits and Branches — Branch and commit management.

• Version History & Comparison — Browse, compare, and restore commits.

• AutoSave — Automatic saving behavior.

• Undo Redo — Reversing individual design operations.

• Review Sessions — Collaborative validation workflow.

• File System — File locations and merge log storage.

• Import/Export Templates — Template management.