You can always mimic exactly what the staging site does with its builds, namely target the build to a checkout of
https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk When the build finishes you can just svn diff that tree to see what you actually changed, but *please* do not commit back those changes yourself. You can nuke all your changes to that tree with svn revert -R so it's handy for testing different types of sledgehammers. HTH >________________________________ > From: Dave Fisher <[email protected]> >To: [email protected] >Sent: Wednesday, January 4, 2012 11:46 AM >Subject: Re: suggested CMS workflows for ooo-site > > >On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote: > >> Given that the size of ooo-site is around 9GB, there >> are some unique challenges here in dealing with the CMS. >> For the most part tho, the typical workflow of editing >> a few pages on the site, committing them, and publishing >> them can all be done reasonably effectively using the CMS >> website. >> >> OTOH, people who need to monkey with templates/** or lib/** >> files will trigger full site builds and their changes may >> materially impact every file on the site. While I've now >> reduced the build time to around 4 minutes, the bottleneck >> now remains squarely in the time it takes svn to commit back >> those changes and to deal with merging those changes during >> publication requests. > >Thanks for your improvements. > >> >> In those circumstances I strongly advise you to use the >> publish.pl script on people.apache.org to review and if >> ok publish your changes. This will eliminate the chances >> that your browser times out a direct publish request to the >> CMS site, which is a real hassle given that it takes ~15 >> minutes for a largeish publish request to be processed. > >I always use publish.pl when I use my sledgehammer ;-) > >I usually test my changes with local build_site.pl or build_file.pl. > >My observation is that the biggest bottleneck is more in the creation of the >email reports. Particularly after publish.pl returns. > >> >> In the near future we will be upgrading svn to 1.7 on the CMS >> server which will bring in better performance along with >> full support for deletions via svn, but I don't expect the >> performance changes to significantly alter the workflow I'm >> recommending here. >> >> And please for the sake of others who want to work on minor >> changes to the site, don't make a sledgehammer type commit >> without following up with an eventual publish request, because >> publish requests are an all-or-nothing type deal. That means >> a sledgehammer commit will cause unreasonable delays for people >> who are trying to publish minor changes to the site, until >> the person who did the sledgehammer commit follows thru and >> publishes everything. > >I would recommend that larger template and skeleton changes with the whole >ooo-site are done locally and fully tested before committing to svn.. > >Do you have any recommendations for comparing a locally built site with >current production in order to understand how big a sledgehammer is being >built? > >Regards, >Dave > >> >> >> HTH > > > >
