| 3 | | 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. Other arguments have been integrated recently. |
| | 3 | There had been 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. Other arguments have been integrated later. |
| | 4 | |
| | 5 | The reader interested by this topic might also be interested by the older proposal: |
| | 6 | * the TighterSubversionIntegration proposal, which was written when Subversion |
| | 7 | was the only VersioningSystemBackend supported by Trac. The ideas in there |
| | 8 | (and I believe in this page too) can actually be transposed to any backend. |
| | 9 | * The newer TracObjectStorageProposal, which suggests that we could actually find |
| | 10 | a way to gain more flexibility in the choice of a backend storage. |
