4 ms·

Ye I believe its best to think of Sqlite not as a database per se but more as a file format, kinda as you would a word doc but a file format that doesn't suck a

• lucioperca 6y ago
  If it is mostly text, then I would say git is better suited.
  • Quarrelsome 6y ago
    git is ACID? I still believe Sqlite is the appropriate store. Unless.. does Git handle power issues elegantly? What happens if you yank power in the middle of a commit? Sqlite is designed to handle that.
    • lbruder 6y ago
      that's one of the reasons I love Fossil so much. Way better backend than Git.
      • utxaa 6y ago
        one of my team members really pushed fossil, and we did like the integrated wiki/ticket system. not bad at all. ... but it was so slow compared to git! at everything. merging, pushing, pulling ... you did not experience same?
        • remram 6y ago
          Fossil has rebasing? I thought they felt strongly against rewriting history, which is the biggest reason I am not considering it.
          • utxaa 6y ago
            oops. corrected. thanks. my main beef with fossil was performance. but i should clarify that this was 5 years ago or so. so maybe it's ok now.
    • megous 6y ago
      Let's see: - A - yes, update HEAD/branch text file is the key atomic update - C - not sure how to apply this in the context of git, because commited files' content is kinda free form by design, no schema, no consistency problems - I - there should not be concurrent use of commands, so no. practically this is mostly important for pushing to remote repository, and there it's handled by rejecting the push that comes second, if you make two commits from the same base and push them at the same time - D - yes
• hodgesrm 6y ago
  And retrieving it, too.