Jeremias Maerki wrote:
> A few months ago, I've set up a publish.xml [1] for the XML site (for
> ForrestBot) which deploys the XML site using SCP. That means the
> generated site isn't committed to SVN anymore. I personally dislike
> putting generated content under version control but infrastructure
> prefers having the generated site in SVN in case they have to restore it
> after a failure. On the other side, we've tried the SVN approach in XML
> Graphics with the result that we have major line-ending problems when
> the site is generated on Windows. SVN complains a lot about mixed line
> endings in Forrest-generated files and the diffs get rather big.

I have been meaning to raise the severity of that
issue, to gain a bit more attention. Done now and
that helped. See:
http://issues.apache.org/jira/browse/FOR-492
"Inconsistent Line Endings in generated sites"

We think that it is related to
http://issues.apache.org/jira/browse/XALANJ-656
"<xsl:copy> introduces inappropriate line-end characters processing comments"

We need to get FOR-492 fixed so that individual
committers can run a local forrestbot like you do
in [1] except with SVN to store the generated docs.

> I don't know how best to resolve this. The best thing would probably be
> a ForrestBot installation on ASF hardware like we had it before. I don't
> know what the plans of the Forrest people are.

It depends on the site-dev@ discussions which stalled
again and were distracted onto other things.

-David

> Anyway, I keep pushing
> this before me because I wanted to concentrate on "more important"
> things. If anyone has a good proposal on how to deal with this, I'm all
> ears.
> 
> [1] https://svn.apache.org/repos/asf/xml/site/publish.xml
> 
> On 16.04.2006 12:41:31 Berin Lautenbach wrote:
> > Prior to moving to SVN for the xml-site module I had a cron job running 
> > that regularly updated the web site from the contents of the xml-site 
> > repo.  I've just updated this (i.e. converted to SVN) for the security 
> > portion of the web site and realised that the similar change has not 
> > been made for the main portion.
> > 
> > Before I go an unilaterally fix this - does anyone object?  Is there a 
> > new way we have been doing it that works better?
> 
> 
> Jeremias Maerki
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to