3 ms·
How does the number of commits in the SQLite repository make it unsuitable as alternate store for git metadata?
by reificator 8y ago
How does the number of commits in the SQLite repository make it unsuitable as alternate store for git metadata?
- Aissen 8y ago@jasode's reply in this thread made a good summary of the two parallel discussions/quid pro quo: - on filesystem vs sqlite (put git files in sqlite): there's a good benchmark on https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html claiming sqlite is up to 35% faster than fs. I'd like to see the same benchmark with git's file pattern; also, it's a known issue with git that it was written for linux first, hence optimized against Linux (relatively) good fs performance (vs Windows and Mac at the time). Same with most OSS build systems that (over)use process forking, which is also very optimized in Linux. - on Fossil vs git (why bother putting git files in sqlite and not directly jump to fossil?): that was my comment, and it relates to subject of this article (the commit-graph). I'm wondering if Fossil has seen the optimization that git has, with regards to number of commits, considering that sqlite is the only high-profile project that uses it. Maybe performance is supposed to be taken care of by the sqlite database itself ? Edit: see https://www.fossil-scm.org/xfer/doc/trunk/www/stats.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/stats.wiki for a fossil-provided performance analysis, that does a comparison with CVS (!).
- deleted 8y ago[deleted]