| 35 | | A compelling idea with many advantages: see a more complete discussion in TighterSubversionIntegration |
| 36 | | |
| 37 | | There has been a discussion on the Trac mailing list that has been summarized in [wiki:WhySQLite WhySQLite]. |
| 38 | | |
| 39 | | |
| 40 | | === Pros === |
| 41 | | |
| 42 | | (some taken from [http://subissue.tigris.org/ Subissue], a project that aims to implement such a solution) |
| 43 | | |
| 44 | | * "Issues are stored directly in your Subversion repository, next to your source — right where they belong!" i.e. you have access to your issues and project documentation (wiki) by just checking out your source. |
| 45 | | * no extra RDBMS required; Subversion already has its own database. |
| 46 | | * "logging, intelligent reporting, history, and access control straight out of the box: most everything required for issue tracking is already in place — right down to email notification." |
| 47 | | * Trac currently mixes transient and non-transient data in a single database. By storing all valuable data (which cannot be reconstructed by resynching with the repository) in a version controlled data store would help separating both sorts of data and minimize the amount of data that needs to be backed up. |
| 48 | | |
| 49 | | === Cons === |
| 50 | | |
| 51 | | * no SQL -- ''There is no reason why Trac might not store "transient" data in a regular database. Such database would be required anyway, because some features of Trac need indexing for fast searching.'' |
| 52 | | * (from [http://projects.edgewall.com/trac/ticket/411#change_3 411]) revision numbers of the repository would climb like crazy because every ticket added or edited would create a new changeset -- ''but a different, dedicated, repository could be used instead the one being Trac'ed'' |
| 53 | | * (from [http://projects.edgewall.com/trac/ticket/411#change_3 411]) trac currently does not modify the repository at all -- changing it to do so might create other problems -- ''If this really is an issue, this could also easily be solved by using a different repository for storing issues and wiki pages.'' |
| 54 | | |
| 55 | | There seem to be more cons :( - the Subissue project [http://svn.haxx.se/tsvn/archive-2004-08/0473.shtml seems to be dead]. ''There are especially no cons without remedy. There are more dead projects than alive ones -- this is no reason for not implementing '''the''' feature that eveybody first thinks of after downloading Trac...'' |
| | 35 | A compelling idea with many advantages. A page advocating this plan is TighterSubversionIntegration. There has also been a discussion on the Trac mailing list. All arguments from this discussion are summarized on the page [wiki:WhySQLite WhySQLite]. |
