Coding Environment

Has anyone setup a coding (development) environment using Subversion + Trac along with DokuWiki? Or CVS + ViewCVS and some WikiEngine? Subversion seems to be more suitable than CVS for our coding needs, and Trac is very good both as a repository front-end and a bug-tracking (trouble-ticket) system. It's just that Trac's WikiEngine should either resemble or better yet use DokuWiki's Engine. What open-source licensed tools have you deployed to assist and suport development tasks?

I've stumbled upon http://www.einval.com/~steve/software/cvs-bugzilla/ where an integration of CVS + ViewCVS + BugZilla + MoinMoin on top of Debian/GNU servers is used. The problem with this integration, IMHO, is using CVS and MoinMoin, which I'd prefer instead to be replaced by Subversion and DokuWiki. As anyone done something similar?

How can InterWiki functionality be of any help in integrating the WikiEngine with the IssueTracker? Considering that a Bug/Issue/Ticket ID should be linked to a Wiki page and wiki pages' content must link to a Bug/Issue/Ticket ID, as anyone done this in a pratical and simple manner?

I'm now evaluating the integration of DokuWiki with Subversion and Mantis/Eventum. These seem to be the best combination, at least for the purposes of the team.

Check out the integration for Dokuwiki and Eventum at http://www.byteflex.com/wiki/pub/dokuwiki_eventum — Chris Usher 2008-09-02

Although the integration with Mantis is stalled for the moment, the team just realized that one good “support feature” that DokuWiki should provide for “Impact Analysis” would be the BackLinks feature. With this feature, one could easily track the documents that link to a specific document. We aim to use this, as an example, to track what impact would a change to a table (which is documented in a TableWikiPage) cause on code in the back-end and front-end of an application. Since the documents for the code also link to the document that describes the table, then the BackLinks of this table document will pin-point some impact on the underlying code.

I'm now evaluating if an RSS Reader is useful or not, in keeping the team posted on recent changes to the WikiSite documents. I'm evaluating RSSOwl, coded in Java, after some successfully evaluations of FeedReader and RssReader (Windows only). The main goal in using a RSS Reader is to have each team member notified about any changes in the documents, and since now DokuWiki can export just the changes of a specific namespace it's even easier to track document changes, just as a successful test report, or a bug fix found report. Some of this information should be even more useful and manageable after integrating DokuWiki with Mantis.

RSSOwl, being coded in Java, is highly portable, handles most of our requirements and has an uncluttered interface. The only requirement that we seem to miss the most is the lack of feed filtering, that RssReader and FeedReader have. Nevertheless, from the 3, RSSOwl seems to be the most fully-featured.

This experience should have a long lifespan. The team is discussing and seeking ways of integrating these areas and systems:

• Collaborative production of high-level technical documentation, using a Wiki Engine. Our choice: DokuWiki.
• Control version and configuration management. The project is split in 3 major blocks: back-end, database and front-end. The major aspect here is how to keep revisions of the front-end graphical user interface and the database. Another important aspect is how to associate an Issue ID with a code revision.
• Issue Management (we call it Incident Management). One of the major aspects is the integration between an Issue ID and a technical document on the Wiki. We also need to adapt to customer expectations about a “transparent” issue management system that doesn't introduce any overhead on current business processes.
• Automatic generation of low-level technical documentation based on sources: Our choice: Doxygen.