Repository does not need to keep a history (git-like)

[enikao]

Is a compatible repository required to keep a history of (almost) all previous states of the model?
This can be helpful (probably even necessary) for version control a la git.

The difference to #293 is in what we mean with "history": Here, we talk about previous states of the model, independent of how we got there. This might include temporarily diverging parallel states (aka branches and merging).

Option A: Repo must keep a history of all states

Pro:

• Would probably support Repository does not need to keep a history (of commands) #293 option A at the same time
• Perfect traceability of changes

Con:

• Potentially huge storage requirement
• Would only make sense if we had an API to access previous states in that history

Option B: Repo must keep a history of most states (aka commits)

Pro:

• Probably more useful than A to users, as they can label each state (aka commit message)
• Less storage than A

Con:

• Still a lot of storage
• Implies user interaction for meaningful messages

Option C: Repo can keep a history of selected states, but doesn't need to

Pro:

• Needed to support versioning (Repo API: Versioning / Collaboration #26)
• Already implemented in lw-repository because it's useful

Con:

• More possible variants a client might need to deal with
• Might need support for Do we support capabilities? #218

Option D: Repo should not keep a history of states

Pro:

• Clients can make some assumption that deleted data is actually gone (might be relevant e.g. for GDPR)

Con:

• Working with digital artifacts without versioning is very undesirable
• No way to enforce it anyways

Decision: Option C

Option A might be too resource hungry. Option B is a step further, but still potentially expensive. Option D cannot be enforced. C is a good compromise.
We accept the increased variability.