Partitioned Code Version History Management

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In programming environments, undoing modifications to program code can inadvertently affect unintended portions of code, making it difficult for programmers to restore specific versions of code without undoing recent modifications across the entire codebase.

Innovation Solution

Implementing a system where program code is partitioned into separate data structures for each portion, allowing for precise version history management and restoration of specific versions without affecting other parts of the code, using an undo/redo stack mechanism.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a single undo mechanism is used for the entire codebase, then the undo operation is simple to implement, but it affects all portions of code and cannot restore specific versions of individual portions

Engineering Contradiction:

Improveease of restoring specific code versionsVSAvoidcomplexity of version history management

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent divides the codebase into separate portions, each with its own data structure storing version history. This segmentation allows independent version management for each code portion, enabling precise restoration without affecting other portions. The system creates a first data structure for a first portion and a second data structure for a second portion, allowing targeted undo operations.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent adds a version dimension to the code structure by implementing undo/redo stacks that store historical versions. This creates a temporal dimension where multiple versions of code portions can coexist, allowing programmers to navigate between versions without modifying the current code structure.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

2Reliability

If version history is stored for each code portion separately, then precise restoration is enabled, but memory usage and data structure complexity increase

Engineering Contradiction:

Improveaccuracy of code restorationVSAvoidmemory consumption for version storage

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The patent extracts the version history storage function from the main code structure into separate data structures (undo/redo stacks). This extraction allows version information to be stored independently, enabling precise restoration while managing memory usage through dedicated storage mechanisms for each code portion.

Inventive Principle:

Principle #2Taking out (Extraction)

3Ease of manufacture

If the entire codebase is treated as one unit for undo operations, then implementation is straightforward, but unintended portions of code are modified

Engineering Contradiction:

Improvesimplicity of undo mechanism implementationVSAvoidunintended code modifications

Core Design Contradiction:

Ease of manufactureVSObject-affected harmful factors

Solution Approach 1:

The patent segments the codebase into distinct portions, each with its own version history. This segmentation ensures that undo operations affect only the intended code portion rather than the entire codebase, eliminating the harmful effect of unintended modifications while maintaining implementation feasibility.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS9063742B1Version histories for multiple portions of program code

Publication Date: 2015.06.23 MATHWORKS INC

AI summary

A device may partition program code into multiple portions. The device may detect a first modification to a first portion of program code from a first version to a second version, and may detect a second modification to a second portion of program code from a third version to a fourth version. The device may detect the second modification after detecting the first modification. The device may store a first version history that identifies the first version, the second version, and a first temporal relationship between the first and second versions. The device may store a second version history that identifies the third version, the fourth version, and a second temporal relationship between the third and fourth versions. The device may receive an indication to undo the first modification after detecting the second modification, and may undo the first modification, without undoing the second modification, based on receiving the indication.