Changes between Version 8 and Version 9 of WhySQLite

Timestamp:

Aug 8, 2005, 12:25:50 PM (19 years ago)

Author:

dave@…

Comment:

Pro-SVN viewpoint

WhySQLite

@@ -32 +32 @@
  7. Using SVN would leverage the benefits of FSFS such as being able to run over NFS.  Current docs discourage using SQLite over NFS if multiple users can access it at the same time.
    * [-] Modern locking on NFSv3 servers may be sufficient for SQLite.
+ 8. With regard to Java projects. Integrating the Wiki into the same SVN instance as the source code leads to some interesting potential features. You can directly link to your .java source code in the wiki. This means that when you fix an issue in the issue tracker, you can directly reference the changed code. All this can be done naturally using the diff information generated by SVN. (dave@daveboden.com)
+   * [+] If you choose to check your JavaDoc into SVN then you could naturally link from your wiki pages to the JavaDoc or even from the JavaDoc to your wiki pages.
+      * [+] A step further is to integrate a JavaDoc processor into the wiki that will generate JavaDoc from .java files. An extremely advanced version might even let you modify the JavaDoc using the wiki and save the changes to the .java files! You can treat JavaDoc as wiki. That is sure to lead to well maintained JavaDoc.
 
 == Pro SQLite ==
@@ -39 +42 @@
      * [+] A backend-independent VC interface has a least common denominator problem (only features supported that are supported by all VC systems) ([http://lists.edgewall.com/archive/trac/2004-August/000625.html trac at nogga.de]).
        * [-] Adding Trac support for other VC systems has the same least common denominator problem, because Trac could no longer make use of unique SVN features. There is no need for supporting other VC systems at all ([http://lists.edgewall.com/archive/trac/2004-August/000625.html trac at nogga.de]).
+   * [-] Integration with other VC systems should be a very low priority compared to creating a feature-rich system based on SVN. SVN is, of course, open source and free. CVS doesn't have the sophistication required to support all wiki features (e.g. you can't rename files...). Let's not get bogged down with the lowest common denominator. (dave@daveboden.com)
  2. As workaround, a macro can include SVN files into wiki contents ([http://lists.edgewall.com/archive/trac/2004-August/000626.html François Harvey], [http://lists.edgewall.com/archive/trac/2004-August/000627.html Mario Ruggier], [http://lists.edgewall.com/archive/trac/2004-August/000628.html François Harvey]).
  3. Trac heavily depends on SQLite and SQL ([http://lists.edgewall.com/archive/trac/2004-August/000603.html Jonas Borgström]).
@@ -44 +48 @@
  4. Revision numbers of the repository would be incremented for every wiki page and ticket added or edited (ticket:411).
    * [-] A different, dedicated, repository could be used for project documentation instead the one being Trac'ed if this is an issue.
+   * [-] I can't imagine a situation where I'm bothered about this. Do you really care if your repository revision is 45 or 345? (dave@daveboden.com)
  5. Trac currently does not modify the repository at all -- changing it to do so might create other problems (ticket:411).
    * [-] "Other problems" is not an argument (haui at haumacher.de)
@@ -50 +55 @@
 == Conclusion ==
 
-Count the [-] and [+] in the pros and cons section. It seems that the  title of the pages was badly choosen.
+Count the [-] and [+] in the pros and cons section. It seems that the title of the pages was badly chosen.
 
 == Another viewpoint ==