There had been recently a discussion in the Trac mailing list why Trac uses SQLite as data store instead of the more natural approach of using a version controlled subversion repository for storage of issues and wiki pages. This pages summarizes this discussion by highlighting the arguments and referencing the original posts.

The following notation is used:

• [number] Introduces a new argument with a unique number.
• [number-] Highlights a statement that (tries to) invalidate(s) the referenced argument.
• [number+] Highlights a statement that (tries to) reestablish(es) or strengthen(s) the referenced argument.

​Alik Eliashberg:

• [1] pro SVN: SQLite is space-expensive, no diffs

​Emmanuel Blot:

• [1-] pro SQLite: diffs could be stored in SQLite instead of full versions
• [2] pro SQLite: SVN integration would counteract support for other VC systems

​Alik Eliashberg:

• [1+] pro SVN: diffs in SQLite would be reinventing the weel by implementing yet another VC system.
• [2-] pro SQLite: Support for other VC systems can be achieved with a backend-independent VC interface.
• [3] pro SVN: manage wiki pages outside of Trac

​Emmanuel Blot:

• [3-] pro SQLite: Removing wiki pages from outside leaves dangling references to this page.
• [3-] pro SQLite: Editing a wiki page in an editor is non-wiki.

​Alik Eliashberg:

• [3+] pro SVN: Dead links are a natural feature of wikis.
• [3+] pro SVN: Editor is more convenient for page creation and large changes. Wiki-Web modifications are means for comunity interaction.

​Denis Gervalle:

• [4] pro SVN: A wiki is well suited for project documentation. Project documentation is an integral part of the project and should be stored in the project repository, access should not be limited to Trac access.

​trac at nogga.de:

• [2+] pro SQLite: a backend-independent VC interface has a least common denominator problem (only features supported that are supported by all VC systems)
• [2-] pro SQLite: Adding Trac support for other VC systems has the same least common denominator problem, because Trac could no longer make use of unique SVN features. There is no need for supporting other VC systems at all.

​François Harvey:

• [5] pro SQLite: As workaround, a macro can include SVN files into wiki contents.

​Mario Ruggier:

• [5] pro SQLite: Shows interest into this proposed macro.

​François Harvey:

• [5] pro SQLite: Announces the proposed macro.

​Jonas Borgström:

• [6] pro SQLite: Trac heavily depends on SQLite and SQL.
• [1-] pro SVN: Disk space is not an issue.

​Toni Brkic:

• [3+] pro SVN: repeation of argument "normal editor is more convenient".

​Toni Brkic:

• [3-] pro SQLite: Pages can also be deleted with trac-admin leaving the same dangling references.
• [7] pro SVN: Less to learn, since people installing trac are already familiar with subversion.
• [8] pro SVN: extra benefits from VC systems like merging/diffing with no extra cost.