How often does the Site Studio project file change? The first determination that needs to be made is what all affects the project file. Some examples are as follows:
While waiting for the the time interval set with SSProjectAutoCheckinInterval, the project file changes are stored in a temp file located here: vault/~ssprojects/
The service SS_COMMIT_SITE_CHANGES can, “Be run at any time to commit changes on demand”. The only required parameter is siteId. “The user executing this service must have write access to the project file to execute the service.”
There is another configuration flag SSAutoCheckinBusyTimeout (integer value in seconds which defaults to 30) that is, “Used to set the minimum time duration (in seconds) before the auto check-in mechanism attempts a check-in of a project file. This configuration flag prevents two nodes from trying to check the project file in at the same time”. The auto check-in behavior appears to use service CHECKIN_ARCHIVE and with the default time of 10 minutes, this should handle any issues that might come up with the release date debacle.
The undocumented configuration flag SSOverwriteProjectsUponCheckin (boolean value which defaults to false) controls whether the latest project file revision is overwritten. So, out of the box, project file auto check-ins stack revisions one on top of the other, instead of simply overwriting the latest revision. This is, is in my opinion, a good thing.
- Adding a new website section (service SS_ADD_NODE)
- Switching content on a region marker in Site Studio contribution mode (service SS_SWITCH_REGION_ASSOCIATION)
- Changing the property of a website section (service SS_SET_NODE_PROPERTY)
While waiting for the the time interval set with SSProjectAutoCheckinInterval, the project file changes are stored in a temp file located here: vault/~ssprojects/
The service SS_COMMIT_SITE_CHANGES can, “Be run at any time to commit changes on demand”. The only required parameter is siteId. “The user executing this service must have write access to the project file to execute the service.”
There is another configuration flag SSAutoCheckinBusyTimeout (integer value in seconds which defaults to 30) that is, “Used to set the minimum time duration (in seconds) before the auto check-in mechanism attempts a check-in of a project file. This configuration flag prevents two nodes from trying to check the project file in at the same time”. The auto check-in behavior appears to use service CHECKIN_ARCHIVE and with the default time of 10 minutes, this should handle any issues that might come up with the release date debacle.
The undocumented configuration flag SSOverwriteProjectsUponCheckin (boolean value which defaults to false) controls whether the latest project file revision is overwritten. So, out of the box, project file auto check-ins stack revisions one on top of the other, instead of simply overwriting the latest revision. This is, is in my opinion, a good thing.
| | | |
RSS Feed
