Where Does Fossil SCM Store Data?
Fossil uses three SQLite files: a per-user config database, one repository file per project, and a checkout database in each working tree.
Last updated
Fossil stores everything in SQLite, but in three separate files with different jobs. The per-user configuration database holds global settings and the list of known repositories. Each project gets one repository file (usually projectname.fossil) containing full history. Each working checkout gets a small state database at its root.
The config database location follows a fallback order, so check rather than assume. On modern Unix setups it lands at ~/.config/fossil.db unless a legacy ~/.fossil file already exists. Repository files live wherever you put them, which makes them easy to lose track of.
Where Fossil stores this, by platform
~/.config/fossil.db
Global settings and the repository list used by fossil all. Older setups use ~/.fossil instead; whichever file already exists wins. FOSSIL_HOME overrides the whole lookup when set.
~/.config/fossil.db
Same Unix fallback rules as Linux: $FOSSIL_HOME/.fossil first, then ~/.fossil if present, then ~/.config/fossil.db. Repository (*.fossil) and checkout (_FOSSIL_ or .fslckout) files sit in your project folders, not here.
%LOCALAPPDATA%\_fossil
Usually %LOCALAPPDATA%/_fossil (note the underscore name on Windows). Set FOSSIL_HOME to pin it somewhere predictable. Each checkout root holds _FOSSIL_ or .fslckout with that tree's state.
Frequently asked questions
How do I find my config database for sure?
Run fossil info inside the checkout and read the config-db line. It prints the exact path Fossil resolved, which beats reasoning through the fallback order by hand.
Can I move a checkout without breaking it?
Yes, with one rule: the repository file must keep its location and name, since open checkouts point at it. Working trees can be renamed, moved, or deleted freely without consequence.
Notice an outdated path? Let us know.