Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
enikao opened this issue Aug 2, 2024 · 0 comments
Closed

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

enikao opened this issue Aug 2, 2024 · 0 comments
Labels

Comments

@enikao
Copy link
Contributor

enikao commented Aug 2, 2024

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:

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:

Con:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant