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

provide strategy for retaining and sharing "repository-state" #30

Open
marc-portier opened this issue Apr 17, 2024 · 0 comments
Open

provide strategy for retaining and sharing "repository-state" #30

marc-portier opened this issue Apr 17, 2024 · 0 comments

Comments

@marc-portier
Copy link
Member

The pain is this:

  • case-a / Whenever I stop and restart my k-gap project I have to wait for all the subyt-uplifting, syncfs-loading and traversal-harvesting to happen and populate my graphdb repo.

But also can be expanded to the more general form inside team-work:

  • case-b / How can I share the build up state from my earlier execution via github (or other file exchange) with team-members that can use it to kickstart their platform with the state-buildup-results I already achieved.

And all of this will hurt even more when we start having a solution for #11

For case-a we could just look into making sure the docker-instance gets an external mountpoint towards data and config that persist when the container stops & restarts.

For the more generic case-b it sounds like we should have a strategy for extract/import state from the graphdb instance in a flexible way. Allowing to (i) orderly extract & store locally at any time (ii) share / copy / transfer that with others so (iii) at start-up some interactive dialogue (or env setting) could result in selecting and preloading the inital state.

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

No branches or pull requests

1 participant