2008/6/2, Jeff Hammel <[EMAIL PROTECTED]>: > For what its worth from a first time mailer to this list, I am glad trac does > not import its wiki pages into an svn repo by default. For my mileage, this > would be clunkier (but I'm sure I have different wiki needs than others).
It is not clear to me how saving wiki pages in svn (or any other vc backend) could be clunkier, given the fact that wiki pages are simply versioned text pages. So, while using the real vcs for the projects 'first class' contents, Trac is implementing its own version control for the wiki pages (and other things, like attachments) and is thus duplicating efforts. Imho *that* is clunkier. Of course the basic problem behind is that people are not (yet) used to the idea that not only a project's source code, but also tickets and other resources (like wiki pages) should go to the same repository. This approach becomes even more elegant if based on a distributed vc system, because it then allows every project member to work on a local copy of *all* of the project's vital data (and not only the source code). In such a scenario, Trac would only be one possible frontend to visualize and manipulate this data. An example of how this could look like, is Fossil [1]. LWN also has an interesting article [2] covering distributed bug tracking, which I think is the right way to go. - Thomas [1] http://www.fossil-scm.org/index.html [2] http://lwn.net/Articles/281849/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
