6 ms·

This reminds be of a talk I watched by Richard Hipp, "Git: Just Say No" [0] where he discusses a "top 10 git enhancements" list, as of the time (4 years ago.) I

by asix66 7y ago

This reminds be of a talk I watched by Richard Hipp, "Git: Just Say No" [0] where he discusses a "top 10 git enhancements" list, as of the time (4 years ago.) It's a good talk, and caused me to discover Fossil SCM. Sadly I've yet to try/use Fossil, and my teams still use git. [0] https://www.youtube.com/watch?v=ghtpJnrdgbo

chmaynard 7y ago
I'm not convinced by Hipp's claim that storing a repo in a single file (SQLite database) is somehow superior to storing a repo in a filesystem directory than contains many files. What am I missing?
- SQLite 7y ago
  I don't actually remember making that argument. But I will try to reconstruct my thinking... (1) Keeping an entire repo in a single file is a better abstraction. There is just one file to move around or rename. There is a single icon on your desktop to drag around or double-click on. There is a single file to attach to an email. There is a single file to measure the size of when judging the size of a repository. And so forth. Lots of programs bundle multiple entities into a single file for convenience like this. For example, a DOCX file is really a ZIP archive containing lots of individual pieces. Would you rather your document be a single DOCX file, or a directory full of the individual pieces. Which would be more convenient to use, do you suppose? How is a VCS repository different from a DOCX file in this respect? Another way to look at this: Breaking up a repository into a directory full of separate files exposes internal implementation details to the user. (2) Perhaps I was making the argument that a relational database is better than a key/value database for holding a repository. (A directory full of files is just a kind of key/value database after all.) There are countless reasons why relational databases work better than key/value databases. One example: With Git, given an individual check-in, it is difficult to discover the descendants of that check-in. It is so difficult, in fact, that none of the common Git tools provide that capability, and Git workflows are engineered (perhaps subconsciously) to avoid the need to ever figure out what comes after a specific check-in. But if Git used a relational database to store content, finding the descendants of a check-in would be a fast and simple query. (3) I/O to a single relational database is faster than I/O to individual files on disk. See https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html for details.
  - chmaynard 7y ago
    Regarding (1), I just ran across an old blog post by Scott Chacon about using git bundles. http://scottchacon.com/2010/03/10/bundles.html http://scottchacon.com/2010/03/10/bundles.html git-bundle documentation: https://git-scm.com/docs/git-bundle https://git-scm.com/docs/git-bundle

by asix66 7y ago

chmaynard 7y ago

I'm not convinced by Hipp's claim that storing a repo in a single file (SQLite database) is somehow superior to storing a repo in a filesystem directory than contains many files. What am I missing?

SQLite 7y ago
I don't actually remember making that argument. But I will try to reconstruct my thinking... (1) Keeping an entire repo in a single file is a better abstraction. There is just one file to move around or rename. There is a single icon on your desktop to drag around or double-click on. There is a single file to attach to an email. There is a single file to measure the size of when judging the size of a repository. And so forth. Lots of programs bundle multiple entities into a single file for convenience like this. For example, a DOCX file is really a ZIP archive containing lots of individual pieces. Would you rather your document be a single DOCX file, or a directory full of the individual pieces. Which would be more convenient to use, do you suppose? How is a VCS repository different from a DOCX file in this respect? Another way to look at this: Breaking up a repository into a directory full of separate files exposes internal implementation details to the user. (2) Perhaps I was making the argument that a relational database is better than a key/value database for holding a repository. (A directory full of files is just a kind of key/value database after all.) There are countless reasons why relational databases work better than key/value databases. One example: With Git, given an individual check-in, it is difficult to discover the descendants of that check-in. It is so difficult, in fact, that none of the common Git tools provide that capability, and Git workflows are engineered (perhaps subconsciously) to avoid the need to ever figure out what comes after a specific check-in. But if Git used a relational database to store content, finding the descendants of a check-in would be a fast and simple query. (3) I/O to a single relational database is faster than I/O to individual files on disk. See https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html for details.
- chmaynard 7y ago
  Regarding (1), I just ran across an old blog post by Scott Chacon about using git bundles. http://scottchacon.com/2010/03/10/bundles.html http://scottchacon.com/2010/03/10/bundles.html git-bundle documentation: https://git-scm.com/docs/git-bundle https://git-scm.com/docs/git-bundle