put conflict resolution under own change control

[samuelstroschein]

Context

In user testing it became clear that conflict resolution itself should be change controlled https://www.loom.com/share/767b66bca84c4eedb66f5c8124f92aae?t=606&sid=f30e9ffb-0def-4525-a727-e50c49c2b912

Proposal

Put the change conflict resolution table under own change control.

Additional information

We discussed if a conflict resolution should be a change previously.

The argument against it was that "If a user chooses change A over change B, that should not lead to a new change for the entity". The spin here is that no new change for the entity is created when resolving a conflict, but the change conflict resolution entity instead.

cc @martin.lysk1 we discussed change conflict resolutions

[samuelstroschein]

@martin.lysk1 it becomes increasingly obvious that everything is a change. Even the change graph itself is the computed result of changes. The only thing that's not updatable are changes.

If we put the change graph under own change control, users can rewrite the graph as they want to, and we can sync it.

Anything that is not a change is derived from changes. Even the graph itself. Crazy insight

[samuelstroschein]

Anything that a user might want to change should eventually be change controlled. If people want to "rebase" aka change their graph, we have to put change edges under own change control. Just like change conflict resolution.

[samuelstroschein]

Heck even change conflicts. A user might want to ignore a change conflict by deleting it. Okay, then delete it. To enable that, the change conflict table needs to be under own change control too.

Everything should eventually be under (own) change control.