Hi, If we go to an svn:externals set in CMS repo, pointing to FOP trunk doc, and 2 last FOP tagged doc, we should take care about having no change in TAGs. Perhaps a pre-commit hook can do the job here, warning the committer, or forbidding the commit propagation.
2014-05-30 23:34 GMT+02:00 Robert Meyer <rme...@hotmail.co.uk>: > I'll definitely look into those. I'm going to be away on holiday now for a > week or so but will continue once I get back. > > Many thanks! > > Robert > ________________________________ > From: Clay Leeds > Sent: 5/30/2014 17:24 > To: Apache FOP > > Subject: Re: FOP Release Automation > > Agreed, ‘some’ people wouldn’t be happy with that. ;-) > > I wonder if the CMS Web interface could be extended to allow for a few > keywords like FOP_VERSION, FOP_REVISION, FOP_BRANCH, etc. > > The CMS tool's WYSIWYG interface indicates it uses the Wysiwym MarkDown > Editor, which is extensible: > > https://web.archive.org/web/20110121060932/http://wmd-editor.com/ > > (site’s down & hasn’t been updated since 2011)... > > or > > https://code.google.com/p/wmd/ > > We might still need to do some ANT hanky panky, but at least if we could > leverage WMD’s extensibility it would help us get where we’re trying to go? > > Clay > > On May 30, 2014, at 7:19 AM, Robert Meyer <rme...@hotmail.co.uk> wrote: > > Hi, > > I like the simplicity of your idea, but the web interface is not so easy to > dismiss unfortunately. > > If you do have a copy with those tags in, if any changes are made on the web > interface then that copy would become out of date. > > We could always shutdown the web interface, but I don't think too many > people would be happy with that ;-) > > Regards, > > Robert > > ________________________________ > From: simonsteiner1...@gmail.com > To: fop-dev@xmlgraphics.apache.org > Subject: RE: FOP Release Automation > Date: Fri, 30 May 2014 14:48:15 +0100 > > Hi, > > > > Simple way is to store docs inside fop repo: > > > > Fop/docs/index.markdown > > > > Inside markdown file you reference ant properties eg: > ${version} > > > > Then you call which does ant expandproperties and calls markdown to html > tool: > ant docs > > > > Then you call which does a zip, scp and unzip of html files to web server: > ant upload-docs > > > > This method doesn’t support web interface of editing files but I don’t see > how this is really needed. > If I submit a patch to fop it should also contain doc changes rather than > having separate repo and patch for that. > > > > Thanks > > > > From: Robert Meyer [mailto:rme...@hotmail.co.uk] > Sent: 30 May 2014 14:05 > To: fop-dev@xmlgraphics.apache.org > Subject: RE: FOP Release Automation > > > > Hi, > > After investigating your suggestions Clay I have found that svn-hooks can't > be used for the purpose we require unfortunately as it may lead to problems > with how SVN operates and also may have some unexpected results with files > being committed. This is stated in the documentation under "Creating > Repository Hooks" highlighted in the warning red box further down: > > http://www-inst.eecs.berkeley.edu/~cs61b/fa09/docs/svn-book-html-chunk/svn.reposadmin.create.html > > Pascal, I agree that the process is fairly straightforward, but I have been > asked to automate this further so am just looking into ideas presently. > > I think a possible way forward then would be to use your suggestion Pascal > of placing the versioned docs for the site inside the FOP repository for > their associated version. These can then be referenced using the > svn-externals from the main site repository. > > In addition to this, the main site files (which would need to be updated) > could contain tags for the last three versions which would be replaced using > Clay's markdown pre-processor suggestion. The pre-processor would replace > the tags with values stored in a properties file in the main site > repository. > > To create a release, the user would need to update the svn-external > references to account for the new version and update the properties file for > tag replacement. When the properties file is pushed it will be read by the > custom markdown pre-processor and display the new version when rendered. > > Those two stages could be done using a single script to simplify things > further, but the main complication is getting the markdown pre-processor > working. From looking at this page: > > http://www.apache.org/dev/cmsref.html#markdown > > I am guessing we use PyPy (Python Markdown) which supports extensions, so I > will look at this shortly to try out a small example and investigate the > feasibility of doing this. There is also the matter of updating the > versioned documents for each FOP when a new version is released, but maybe > this could be done with the pre-processor as well. > > Anyway, let me know what you think. > > Regards, > > Robert > > -- pascal