forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Creating documentation (Re: Link to CSS howto-structurer-dsl.html)
Date Mon, 19 Dec 2005 11:43:24 GMT
David Crossley wrote:
> There is a problem, and the Cocoon project has not
> solved it.
> 
> There is a requirement to have the sources stored in
> the ASF Subversion repository. We also store the generated
> products (html/pdf/) in svn, but that is just a convenience.
> The main issue is that the sources are an asset and we
> must have them stored in the ASF svn.

Well I've seen nobody in infra confirm that it is a problem, only lots 
of people saying it *may* be a problem. The last message on infra was 
sort it out on site-dev - which we haven't done yet. Infra are waiting 
for a proposal from what I can tell.

Perhaps we should move this discussion there, and pull over some of the 
Cocoon, Daisy and Lenya folk too.

> Does anyone have solutions? Here are a couple of ideas.

Before I get into your ideas. I'd like to remind us all that the Lenya 
team have said we could have SVN as the back end for a Lenya repository. 
If that were created and we had a stable instance to work with then 
problem solved and no discussion needed (at least for Forrest's use).

> I wonder if we could have a special Ant build target
> that copied the source files from the "CMS", and committed
> those to our SVN.

Yes, this could be done. However, it would not give us true version 
tracking, since who made what changes would be lost. We could extract 
the version history from Daisy as well and put that in SVN, but that 
just feels wrong, we would end up with a document in SVN describing the 
version history. We would also be duplicating stuff across two 
repositories, but for what purpose other than to hold of those at infra 
who may think it is a problem.

Perhaps a better approach would be to add a hook into the Daisy 
repository that, upon a document save, wrote the XML representation of 
the file to SVN as well as recording the info in the Daisy back end. The 
commit message in SVN could contain the Daisy username of the editor.

Another set of solutions along these lines is being considered by the 
Daisy devs themselves. They are wanting to create a publish only 
framework for Daisy. As with their wiki they want to keep a clear 
separation between the publish engine and the repository. This is great, 
because it means Forrest can integrate even more closely with the 
repository, that is it would know when a document has changed and 
therefore needs to be regenerated.

It's still in the "random thoughts" stage [1] In short, the idea would 
be that a client is written to listen to the messages from the server. 
That client could then, for example, write the changes into SVN, this 
still feels wrong though, we are still duplicating content between 
repositories and I see no benefit in that.

Let me ask a question, why do you feel infra require us to have the data 
in SVN? (that question is aimed everyone reading, not just David)

> Alternatively could we have a specialised forrestbot build
> that can do it.

Yes, but... as above, we would lose the version control aspects of SVN 
since it would be a periodic build. It would cover backup but if that is 
all we get I would prefer to see a script to build a tar ball and dump 
that into SVN - less resource intensive.

Ross

[1] http://www.cocoondev.org/daisyscratchpad/g1/241.html

Mime
View raw message