Charts and version control

Question

I have a diagram structure of a directed graph, where I try to implement individual version control for each vertex. This creates some interesting scenarios, and I will be very grateful for any ideas that you have. In particular, I am looking to allow the default behavior of the system when it encounters the specified scenarios.

See the following image: Graphic versions

Scenario 1: The Null Pointer Paradox

Vertex A returns to version 1.0. Since this rollback will cascade down its subgraph, C will no longer point to D. This can create a danger. If the behavior should be:

• 1.1: Remove edge C → D, creating a broken graph
• 1.2: Remove D, leaving E orphaned
• 1.3: Delete D and E
• 1.4: Refuse to rollback before all edges pointing to D (which in this case will be E → D) are deleted.
• 1.X: Alternative solutions?

Scenario 2: Indirect Effects

Vertex D is updated, so the following is true:

• D is now version 1.2
• E is now version 1.1
• C is now version 1.3
• Now version 1.3

Vertex A is now rolled back to version 1.2, so the following is true:

• Now version 1.2
• C is now version 1.2
• D is now version 1.1

If the default behavior is:

• 2.1: Rollback E to 1.0
• 2.2: Refuse rollback due to danger of the version, which actually exacerbates the functionality
• 2.X: Alternative solutions?

Answer 1

It seems to me that there is some confusion in detail. If you use only individual vertices, but not a graph, then rollback of an individual vertex should not affect the rest of the graph. If, OTOH, you want the whole chart to be rolled back, then you should also look at the whole chart.

The problem is that if you are only versions of individual vertices, then you only have integrity guarantees for individual vertices, but not for the graph as a whole. So, if, as you described it, the rollback of an individual vertex “ripples” throughout the schedule (or at least the connected subgraph), then you cannot guarantee yourself in a consistent state.

The study, which seems to be closest to what you are trying, is about version control for XML, which, however, only applies to strongly typed trees (degenerate IOW graphs), and not to general graphs.

Answer 2

What you are processing is a very complex problem, and although I am not aware of specialized research projects specifically related to this, I have heard some attempts to solve the problem. in principle, it is impossible to pull out a quick and dirty solution. I can point out the previous questions that I asked in this regard (graphs and version control):

• triplestore with changes
• RDF graphical databases and triplets: storing graph data in python

As a result, I refused to carry out any version control, but each time I created new nodes with new identifiers. I lose rollback, I lose any tracking, but I kept the thing manageable.

In practice, the only thing you can do is have version control for the entire graph. It is very difficult to use it for individual nodes. All the problems you described arise because you are intersecting levels of transactions, where at each level you have a consistent graph formed at a certain point in time. If you cross these layers, allowing you to control the revision of the vertices, you are dealing with a can of worms the size of Dune.

Answer 3

Antiquity is the version for the version for Blueprints (this way it works with neo4j as well) Take a look at: https://github.com/asaf/antiquity