lix-project/lix
20
57
Fork 31
Code Issues 347 Code Review (Gerrit) Projects 3 Releases Wiki Activity

move git comparison to related work

Browse source 
it should be pulled out of the branch before we go for merging
This commit is contained in:
Valentin Gagarin 2022-04-28 10:16:27 +02:00
parent a145007a57
commit e5e48593c8
2 changed files with 24 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/manual/src/architecture/store/objects.md
View file

@ -31,29 +31,6 @@ In particular, every file system object falls into these three cases:
A bare file or symlink as the "root" file system object is allowed.
### Comparison with Git
This is close to Git's model, but with one crucial difference:
Git puts the "permission" info within the directory map's values instead of making it part of the file (blob, in it's parlance) object.
data GitObject
= Blob ByteString
| Tree (Map FileName (Persission, FSO))
data Persission
= Directory -- IFF paired with tree
-- Iff paired with blob, one of:
| RegFile
| ExecutableFile
| Symlink
So long as the root object is a directory, the representations are isomorphic.
There is no "wiggle room" the git way since whenever the permission info wouldn't matter (e.g. the child object being mapped to is a directory), the permission info must be a sentinel value.
However, if the root object is a blob, there is loss of fidelity.
Since the permission info is used to distinguish executable files, non-executable files, and symlinks, but there isn't a "parent" directory of the root to contain that info, these 3 cases cannot be distinguished.
Git's model matches Unix tradition, but Nix's model is more natural.
## References

24
doc/manual/src/architecture/store/related-work.md
View file

@ -25,6 +25,30 @@ Do we have open terms?
Do we hve thunks vs expressions distinction?
c.f. John Shutt's modern fexprs, when the syntax can "leak".
## Comparison with Git file system model
This is close to Git's model, but with one crucial difference:
Git puts the "permission" info within the directory map's values instead of making it part of the file (blob, in it's parlance) object.
data GitObject
= Blob ByteString
| Tree (Map FileName (Persission, FSO))
data Persission
= Directory -- IFF paired with tree
-- Iff paired with blob, one of:
| RegFile
| ExecutableFile
| Symlink
So long as the root object is a directory, the representations are isomorphic.
There is no "wiggle room" the git way since whenever the permission info wouldn't matter (e.g. the child object being mapped to is a directory), the permission info must be a sentinel value.
However, if the root object is a blob, there is loss of fidelity.
Since the permission info is used to distinguish executable files, non-executable files, and symlinks, but there isn't a "parent" directory of the root to contain that info, these 3 cases cannot be distinguished.
Git's model matches Unix tradition, but Nix's model is more natural.
## Machine models
TODO