Corporate Software Development Wiki?

gnujoshua asks: "My company would like to expand the use of its Wiki to include source code and API documentation. It would be nice to have auto-generated, syntax highlighted, and well documented source code, integrated nicely into the Wiki. Ideally, changes to source could be made right in the Wiki, barring permissions, and furthermore, it would be nice to see if it compiles against the library as well. What recommendations does Slashdot have for Wikis and scripts that could be used effectively to this end?"

Comments

TWiki already uses RCS

[mrm677]

Interesting idea to integrate a Wiki with a version-control browser. I wouldn't want to use a Wiki as my editor however.
 
  TWiki uses RCS as its backend. Thus if you use CVS for version control (which is based on RCS), modifying the Perl-based TWiki to talk with your CVS repository should be feasible.

Re:TWiki already uses RCS

[Raphael]

TWiki uses RCS as its backend.

TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).

I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.

Google

[GameMaster]

You know, I recommend Google. For instance it took me less than a minute searching on Google to find this http://qbnz.com/highlighter/. It's called GeSHi, and, apparently, it is an open source library for generic syntax highlighting. Maybe you could put just a little bit of effort into looking for a solution before you try to get a community of thousands to spend their time doing it for you. A good first step would be to find your own answer to the other few problems you mentioned now that I've given you one for free.

-GameMaster

Re:Reinventing the wheel?

[jgrahn]

All the options you listed [CVS, SourceSafe and Sourceforge] are for engineers only. If only engineers are involved in your design and development process, that's fine. For us, wiki is a great way to document our software development so that it is accessible not just to software developers, but also to documentation developers and tech support.

Version control is not just for programmers. It is applicable for almost all computer work, for keeping history, creating an audit trail, enable people to work together, and a great many other things. It makes work easier and more fun. Not using at least basic version control is barbaric, and a waste of time and energy.

There is this widespread notion that version control is hard to learn, or "for the programmers", or that "it takes time", and (as you can observe) it pisses me off.

Your organization might still prefer a wiki, of course. But please do so for valid reasons.

Also: cvsTrac, FitNesse, and WikiBase

[boustrophedon]

Long before Trac for Subversion, there was CVSTrac for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

FitNesse combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and others). Although written in Java, FitNesse also can test Python, Ruby, C++, .NET, Smalltalk, and Perl applications. FitNesse builds on Fit, the Framework for Integrated Testing by Ward Cunningham, the creator of the original Wiki.

Ward also was the first person to integrate source code into a Wiki. In his WikiBase , Ward presents the source code for his original Wiki on Wiki pages containing HyperPerl, a Perl implementation of Literate Programming. This may not suit current development needs, but it is fascinating.