| 66 | | * [-] Counting pros and cons is a bad way to evaluate an argument, because different points can have vastly have different weights. For example: "Should I eat? Pros: I will survive. Cons: I might get indigestion." Well, looks like 1 for and 1 against, so it's a draw! |
| | 66 | * [-] Counting pros and cons is a bad way to evaluate an argument, because different points can have vastly have different weights. For example: "Should I eat? Pros: I will survive. Cons: I might get indigestion." Well, looks like 1 for and 1 against, so it's a draw! |
| | 67 | * Even taking into account that some points are more important than others it seems very clear from reading the above listing that ''way'' more advantages and interesting possibilities have been pointed out with the suggested approach than possible problems. Note that there is not a single "pro SQL" argument that has not been argued against/refuted in a sensible manner ''and'' not a single "pro SVN" argument, that has been left with an invalidating argument. Judging from the [http://projects.edgewall.com/trac/wiki/WhySQLite?action=history Page History] this argument seems to have been settled quite clearly. |
| 72 | | * alternative storage could also be ZODB - which would provide a more natural way to store python objects, |
| 73 | | has indices, has all historic data for timetravel and does not require the user to install yet another |
| 74 | | program in conjunction with trac and svn (and apache) - afaic one of tracs main goals is to "go out of the |
| 75 | | way" of the programmer. ZODB can also be used across networks and used to inject data just like the |
| 76 | | alternative SQL databases. And you avoid pollution of the SVN with wiki data. |
| | 71 | * trac isnt long since bound to SQLite only - there are adapters for postgres. |
| | 72 | * [+] this helps to marry trac with other information sources when you are able to inject data w/o the web interface |
| | 73 | * [-] this does not touch the listed arguments for SVN-integration at all. Swapping PostgreSQL for SQLite won't help accessing documentation (and what else is a wiki) using $EDITOR, does it? |
| | 74 | |
| | 75 | * alternative storage could also be ZODB - which would provide a more natural way to store python objects, has indices, has all historic data for timetravel and does not require the user to install yet another program in conjunction with trac and svn (and apache) - afaic one of tracs main goals is to "go out of the way" of the programmer. ZODB can also be used across networks and used to inject data just like the alternative SQL databases. And you avoid pollution of the SVN with wiki data. |
