[coyotos-dev] Documentation: CMS or SCM?

[Jonathan S. Shapiro]

On Mon, 2007-09-03 at 01:21 +0100, David Hopwood wrote:
> Jonathan S. Shapiro wrote:
> > First, Trac is not an SCM.
> 
> I didn't say it was. For the CMS to provide its own SCM would be
> redundant; all you need is for it to interface (perhaps "integrate" was
> the wrong word) with the SCM that is being used for the Coyotos source,
> Mercurial.

I think we are talking past each other.

The goal here isn't to be be able to see the change control on the
document. That can be accomplished in any number of ways.

The minimum goal here is to render the document directly from the change
control system, having it appear as an SCM page. That proves to be hard,
because of the need to translate href's across the boundary.

Equally good would be to have a document whose versioning could be
handled within the SCM system.

> The main difference between a wiki-with-page-history, and a wiki that
> stores its content in an SCM, is that in the former the page histories
> are independent: there is not any notion of a version of the whole wiki,
> only versions of pages. OTOH, I think it would be possible to simulate
> whole-wiki versions (or versions of specific multi-page documents) by
> using the tags plugin for Trac.

Perhaps. I think there is more to it, but I haven't given it a lot of
thought. The question at bottom is to define what constitutes a
"document". That is the proper unit of versioning, regardless of the
number of "pages" involved.

But we digress. I don't know of any production-grade wiki today that
uses a change control system as it's back end, and I don't have time to
engage in wiki development on any significant scale.

> And a source/changeset browser, and a template engine
> (http://genshi.edgewall.org/).

These are plug-ins. They do not impact the core schema and theory of
operation of Trac.

> 
> [...]
> > Second, Trac is what we initially tried, and we concluded that it is
> > hopelessly inadequate for our needs. The bug tracking model does not
> > incorporate the notion of a product with multiple components.
> 
> The current version definitely does support that.

We have a terminology problem. We need something that supports a
hierarchy of components within products. Trac does not do that. What
Trac does is mis-label products as components.

> In fact it seems as though Trac has come on quite a bit recently, and
> should be reevaluated.

Since our evaluation ended last week, I suspect there have not been
overwhelming advances in Trac since we looked at it. :-)


It is certainly possible that we were not using Trac to full effect. At
this point the decision is made.


shap