How Snapshots Help

One way that a snapshot is used is to validate that a deployment was done correctly. Because the source items for a component is deployed in the order in which they are listed in the component's XML file, it's possible for one source item to overwrite another that has already been deployed, if they both have the same name.

For example, you may have a component that installs the source for a component named pockets onto a host. One source (S1) of the pants component, pants/config.txt may be deployed, followed by a second, different source (S2), also pants/config.txt. If you were then to go and look at pants/config.txt you might think you were looking at S1, when in fact, config.txt now reflects the contents of S2. To avoid this sort of difficulty, you can define a snapshot that the provisioning software can use to make sure the correct baseline, post installation version of config.txt is used in any Model-to-install comparisons.

Another way snapshots are useful is when a component's source items might be transformed using the transform element, or otherwise changed during the course of deployment by an execNative call that you have defined. Without a snapshot of the “just installed” state, a Model-to-Install comparison would be made against the source items before they were deployed, which would lead to errors in the results.

It is not necessary to define a snapshot block, or specify that one be used, in your components. However, if one is not specified, the installed component that you are comparing against the model will contain no snapshot information, and will never present any differences.