Importing Generates New Tree Rather Than Versioning #34
Description
If the same CAR file is imported twice in a row, the second time should have no effect on the state of the graph because the current state of the graph will be in sync with the first import.
There is some contention as to how to store versioned file sets in the graph…
Perhaps the simplest system is, while doing an import, if a file is added that already exists and it has a different CID than the existing entry, then a PREVIOUS relationship is stored to the existing Nöopoint from the newly created one. All the PREVIOUS links for a given import have the same import_id and imported_at properties.
If a file is removed, put a :File:Deleted placeholder in with a PREVIOUS link to the last version. Likewise if a new file is added where one did not exist, put in a :File:Preexistant node and add an appropriate PREVIOUS link to it.
To find the state of a directory at a given point, start with all the files in the directory and its descendants. Follow the PREVIOUS links where necessary to get to the versions that were present at that particular revision. (Is this feasible?)
Currently, when the same CAR file is loaded twice, it generates the same structure in two parallel graphs, as evidenced in this expansion:
One of the planned features is to be able to check out subsets of a directory without needed to pull all the files. I don't see a reason why this should be a problem with this layout.
When git is merging changesets, it verifies that the previous version in the repository is the same previous version that the local files have. If there is a difference, it does a merge where the committer reconciles the differences. To replicate this functionality would require tracking what the previous version is for each checked out version.
Ju-Jitsu uses a different commit concept that might work better. More research is required.