Part revision numbering scheme conflicts when merging design branches

When merging CAD design variants from parallel development branches, we’re encountering part revision numbering conflicts that break data integrity and lineage tracking. Our team develops design alternatives in separate branches, then merges the selected variant back to the main product line.

The problem: Both branches independently increment revision numbers (A, B, C…) during development. When we merge branch-2’s revision C into main, it conflicts with main’s existing revision C, causing the merge operation to fail with a duplicate revision error.

Our distributed revision numbering scheme doesn’t account for branch-aware versioning. We need merge strategies that intelligently handle revision number collisions while preserving the complete version history from both branches.

The error during merge:


RevisionConflict: Part 1234-567 revision C exists in target
Source: branch-2/rev-C, Target: main/rev-C
Merge operation aborted - manual resolution required

Version control integration with our CAD system (Creo) adds complexity since CAD workspace versions need to stay synchronized with Windchill revisions. How do others handle revision numbering across branch-based development workflows?

You don’t need to migrate historical data - implement a forward-looking solution that handles new branches correctly while maintaining backward compatibility. Here’s a comprehensive approach addressing all four focus areas:

1. Distributed Revision Numbering Schemes (Architecture): Implement a hybrid numbering system that distinguishes branch revisions from main-line revisions:

Main-line revisions: Continue using standard alphabetic scheme (A, B, C, D…) Branch revisions: Use branch-prefixed scheme (BR1-A, BR1-B, BR2-A, BR2-B…)

Configure this in number generation rules:

// Pseudocode - Branch-aware revision numbering:
1. Check if part context is branch or main-line
2. If branch: Generate revision with branch prefix (BR{branchId}-{letter})
3. If main: Generate standard revision (letter only)
4. Store branch origin metadata in revision attributes
5. Maintain cross-reference to parent branch revision
// See Windchill PDMLink Admin Guide Section 8.3

This approach keeps branch revisions distinct while maintaining familiar numbering for main-line development.

2. Branch-Aware Merge Strategies (Core Process): Implement intelligent merge logic that handles revision conflicts:

Scenario 1 - Clean Merge (no conflicts): Branch revisions map directly to next available main-line revision:

  • Branch BR2-A, BR2-B, BR2-C merge to main-line as new revisions D, E, F
  • Branch lineage preserved in revision predecessor relationships

Scenario 2 - Conflicting Revisions: When branch revision letter conflicts with existing main-line revision:

  • Create new main-line revision with next available letter
  • Example: Branch BR2-C conflicts with existing main-C → becomes main-D
  • Add merge metadata linking main-D back to BR2-C origin
  • Preserve both main-C and main-D as parallel lineage branches

Scenario 3 - Selective Merge: Merge only specific branch revisions, not entire branch history:

  • Cherry-pick desired branch revision (e.g., BR2-E)
  • Create new main-line revision incorporating changes
  • Maintain reference to source branch revision in merge attributes

Implement merge validation workflow:

  1. Analyze source branch and target main-line for conflicts
  2. Generate conflict resolution plan with proposed revision mapping
  3. Present plan to configuration manager for approval
  4. Execute merge with automatic revision renumbering
  5. Update all dependent objects (CAD assemblies, BOMs, documents)

3. Version Control Integration (CAD Synchronization): The Creo workspace synchronization is critical. Implement post-merge workspace update process:

Step 1 - Pre-Merge Workspace Snapshot: Before merge, capture all Creo workspace configurations referencing branch revisions

Step 2 - Revision Mapping Table: During merge, create mapping table: BR2-A → main-D, BR2-B → main-E, BR2-C → main-F

Step 3 - Workspace Update: After successful merge, update Creo workspaces:


// Workspace configuration update script
creo_workspace.updateReferences(
  oldRevision: "BR2-C",
  newRevision: "main-F",
  cascadeToAssemblies: true
)

Step 4 - Verification: Validate that all workspace references now point to post-merge main-line revisions. Run consistency check to ensure no orphaned branch references remain.

Critical: Notify all designers with active workspaces that reference merged branch revisions. They must refresh workspaces to pick up new revision references.

4. Lineage Tracking and Governance (Audit Trail): Preserve complete development history through merge operations:

Lineage Metadata Schema: For each merged revision, store:

  • sourceBranch: Original branch identifier (BR2)
  • sourceRevision: Original branch revision (BR2-C)
  • mergeDate: Timestamp of merge operation
  • mergeOperator: User who performed merge
  • conflictResolution: How revision conflicts were resolved
  • predecessorRevisions: All parent revisions from both branches

Governance Reports: Implement traceability reports that show:

  • Complete revision history across all branches
  • Merge points and branch integration timeline
  • Impact analysis: Which main-line revisions originated from which branches
  • Conflict resolution decisions and justifications

This satisfies audit requirements by maintaining full design lineage even through complex merge operations.

Implementation Roadmap:

Phase 1 (Weeks 1-2): Configure branch-aware revision numbering for new branches Phase 2 (Weeks 3-4): Develop merge workflow with conflict detection and resolution Phase 3 (Weeks 5-6): Implement Creo workspace synchronization logic Phase 4 (Weeks 7-8): Deploy lineage tracking reports and governance dashboards Phase 5 (Weeks 9-10): Pilot with one product line, refine based on feedback Phase 6 (Weeks 11-12): Roll out enterprise-wide with user training

Backward Compatibility: Existing parts with simple alphabetic revisions continue working unchanged. The new branch-aware numbering only applies to new branches created after implementation. This avoids the need to migrate historical data while solving the problem going forward.

The combination of branch-prefixed numbering, intelligent merge strategies, CAD workspace synchronization, and comprehensive lineage tracking provides a robust solution that scales to complex parallel development scenarios while maintaining data integrity and audit compliance.


This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

This is a common challenge with branch-based development. The fundamental issue is that alphabetic revision schemes (A, B, C) assume linear progression, which breaks down in parallel development scenarios.

Consider switching to a hierarchical revision scheme that incorporates branch identifiers: main-A, main-B, branch2-A, branch2-B. This makes revisions unique across branches but requires significant process changes.

Your version control integration with Creo is critical here. Creo workspaces maintain their own version tracking that needs to stay synchronized with Windchill. When you merge branches, Creo workspace versions don’t automatically remap to new Windchill revision numbers.

You need a merge process that updates Creo workspace configurations to reference the post-merge revision identifiers. Otherwise, designers end up with workspace references pointing to pre-merge revisions that no longer exist in the main branch context.

Tested this on Windchill 12.1 and the hybrid BR-prefixed numbering scheme in the number generation rules cleanly prevented revision conflicts during our multi-branch PDM merges.

Lineage tracking is the most critical aspect here. When you merge branches, you must preserve the complete development history from both branches. Simply renumbering revisions during merge breaks the audit trail and makes it impossible to trace design decisions back to their branch origin.

Implement a merge strategy that maintains branch lineage metadata alongside the merged revisions. This allows you to trace any revision back through the merge point to its original branch context.

We solved this by implementing branch-aware revision numbering from the start. Each branch gets a unique prefix, and we use composite revision identifiers that include branch context. During merge, we map branch-specific revisions to new main-line revisions while preserving the branch history as predecessor relationships.

The key is treating merge as a first-class operation that creates new revisions rather than trying to transplant existing revisions between branches.

We’re exploring the composite revision identifier approach. The challenge is that our existing parts already have thousands of revisions using simple alphabetic schemes. Migrating to a new numbering system would be a massive undertaking affecting all our historical data and CAD workspaces.