- From: Robie, Jonathan <jonathan.robie@emc.com>
- Date: Wed, 7 Oct 2015 11:45:13 +0000
- To: Adam Retter <adam@exist-db.org>, Michael Kay <mike@saxonica.com>
- CC: Liam Quin <liam@w3.org>, Public Joint XSLT XQuery XPath <public-xsl-query@w3.org>
+1 Jonathan ________________________________________ From: Adam Retter [adam@exist-db.org] Sent: Wednesday, October 07, 2015 6:20 AM To: Michael Kay Cc: Liam Quin; Public Joint XSLT XQuery XPath Subject: Re: Making editors' drafts public On 7 October 2015 at 09:01, Michael Kay <mike@saxonica.com> wrote: > While we’re about it, is there anything we can do to reduce the problem of CVS conflicts on the generated HTML? > > What typically happens to me as that I do a build, try to commit, and get a commit failure because someone else has done a build in the meantime and so my HTML files are not “up to date”. I then typically revert the HTML and do a new build - all very time-consuming. CVS doesn’t know that they are generated files and therefore there is no need for them to be up to date. Perhaps the build scripts should do an automatic CVS update on the html directory at the start? > > Normally I would say that automatically-generated files shouldn’t be held under a version control system. But then we need a different way of uploading them. Perhaps this is our opportunity. > Exactly. Presumably the generate HTML files could just be published to the web server, rather than committing them to CVS also? *if* we were to use GitHub, we could automate the build and publish process by throwing Travis into the mix, this would allow our build scripts to run on every commit and on success have the artifacts (e.g. the latest HTML draft spec) published to the web. -- Adam Retter eXist Developer { United Kingdom } adam@exist-db.org irc://irc.freenode.net/existdb
Received on Wednesday, 7 October 2015 11:46:09 UTC