3 ms·
If you have a database of atoms and plans, the V is a row in a plan table, and you reconstruct history using plan edit distance, which is more robust than manua
by CuriouslyC 1y ago
If you have a database of atoms and plans, the V is a row in a plan table, and you reconstruct history using plan edit distance, which is more robust than manually assigned provenance anyhow (it will retain some history for cherry picked changes, for instance).
I'm sure there would be new issues, but I think they'd be at the management/ops level rather than the individual dev level, which is a win since you can concentrate specialization and let your average devs have better DX.
Is it a weird use case? Imagine you refactor some code, but then you realize that a function was being called in a slightly incorrect way after a change (prior to the refactor so the revert isn't trivial) and you have to go back and revert that change, let's say over 100 files to be fun, and let's say that the code isn't perfectly identical. With git you probably have to do surgery to create a patch, with an atomic system you can easily macro this change, or you could even expose a UI to browse different revisions of a piece of code cleanly (which would blow up with git).
- mpalmer 1y agoif I make a plan which causes the project to be identical to its state 5 years ago, the edit distance is zero, but in no way can you call that a measure of history
- CuriouslyC 1y agoYou're still thinking in graphs. That plan would already exist in the database, you would just be making it a build target instead of whatever new plan was targeted before.
- mpalmer 1y agoIt seems as though you've come up with a model for representing source code repos in terms of a data model of your own design, solving problems of your own choosing. But what you describe is not a version control system in the generally agreed upon sense of the word.