--- Emmanuel Blot <eblotml at free.fr> wrote: > 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. This is essentially how version control system works - so effectively Trac would have to implement a version control system. It is not rocket science to do, but is that within the scope of the project? > I read that Trac future features include support for alternative source > control software. Adding a dependency on a specific one should be avoided. Well, that means that Trac would have to develop some sort of a "backend-independent" version control interface. That means that it can use whatever the current version control system for its wiki. Another nice benefit for having an external version-control system used for wiki backend would be the ability to add/remove/manage wiki pages outside of Trac. For example, through some sort of a gateway that updates FAQ wiki nightly based on some criteria (like new entries in the internal KB). This certainly can be achieved through extending trac-admin as well, but again, it seems to me to be outside of the scope of the project. Alik __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail