Discussions
Categories
Choose a Product
THRUST SERVICES
CORE APPS
CE PRODUCTS
...
Quick Links
POPULAR
HELPFUL TIPS
Groups
My Links
FOR SIGNED IN MEMBERS:
Back to website
Home
TeamSite
TeamSite, LiveSite and OpenDeploy
Regenerate STAGING
System
I may have posted this before but if so I don't think there were any responses.
There is much use of iw_include in TPLs and because of the way navigation is (mis)managed here the entire site has to be generated every night, then an EDITION is created and deployed. One problem is that regeneration can't be done in STAGING (since STAGING is readonly) and it can't be done in the WORKAREA (since that might pick up unapproved changes to DCRs, TPLs, include files, etc.), so it's done in a temp workarea with a get latest from STAGING. Resultantly the workarea does not contain the latest content which tends to result in those user-friendly submit conflicts, which means telling users to always overwrite which may work but is pretty lame.
I was thinking of having a process regenerate in the WORKAREA using the content in STAGING using iwpt_compile.ipl, passing the WORKAREA path to the output file but the STAGING path to the DCR, PT and iw_include location, and smartwrite. After generation, if Interwoven thinks the output file has been modified, submit it and then regenerate it with the WORKAREA copy of includes, TPLs and DCR but don't submit that version (so the WORKAREA shows the unapproved DCR change but STAGING does not). I am not sure if Interwoven would think a file that had been regenerated from STAGING in this way had been modified even if the content in both WORKAREA and STAGING were the same so I might use diff instead of iwattrib to determine if the output file had changed.
Any comments on whether this is a bad idea?
This would fit my strong belief that there should never be more than one workarea on branches used to develop only content and not applications.
Find more posts tagged with
Comments
There are no comments yet