4 ms·

If it is mostly text, then I would say git is better suited.

• Quarrelsome 5y 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 5y ago
    that's one of the reasons I love Fossil so much. Way better backend than Git.
    • utxaa 5y 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 5y ago
        Fossil has rebasing? I thought they felt strongly against rewriting history, which is the biggest reason I am not considering it.
        • utxaa 5y 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 5y 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