Alik Eliashberg wrote: >With current use of SQLite, having a dynamic wiki (one that changes >frequently) becomes very space-expensive - every time a document is changed, >it is completely duplicated in another entry of 'wiki' table. > I do agree on the first statement: SQLlite stores all versions of each Wiki page, with no 'diff-like' system, which can make Wiki quite large ... for very large Wikis. I'm not sure storing it inside a Subversion repository is a better approach, however. However, an improvement could be to store the last version of a Wiki page as plain text, and store previous releases as reverse diffs, for example. Older page are rarely browsed, and diff computation time could be acceptable for those pages. I read that Trac future features include support for alternative source control software. Adding a dependency on a specific one should be avoided. >Second (and unrelated) question is why does Trac use SQLite for its internal >storage? > I guess that some clues would be: * SQLlite is ... lite and very fast. You cannot get that speed with a BDB database. Do no forget Trac Wiki pages are generated on-the-fly. * BDB does not support SQL interface. Which means another layer should be added to translate SQL statement into BDB requests * SQLlite provides all the features Trac needs. BDB would be an overkiller for this kind of application * It is not true anymore that Subversion uses BDB: it can use BDB, but it also can use its proprietary repository backend (FSFS, starting release 1.1). Trac should not add a dependency onto BDB if one uses Subversion FSFS backend * ? Regards, Emmanuel.