ChangeSets for Distribution

A ChangeSet is a file containing everything required to install a VTScada application on a workstation. They exist to distribute applications and updates for those applications to computers where "Get From Workstation" is not an option. The name describes the file: it is the set of changes that created the application. In other words, the version log.

Depending on how it was created, a ChangeSet may have the extension .ChangeSet, .Snapshot, or .Template. Each is a different type of a ChangeSet, meant for a different purpose. In this chapter, all are referred to as "ChangeSets".

Always use the right tool for the job:
* Use the VTScada Version Control system to roll back to an earlier version. NEVER use a ChangeSet for that purpose.

* In a networked environment, restore a workstation using Get From Workstation (Add New Applications). NEVER restore a networked workstation using a ChangeSet. A repository clash would be the likely result.

* If restoring a workstation that is not connected to a network, use a new ChangeSet created on a workstation that is up-to-date. NEVER use a ChangeSet that is older than the current version of your application.

* If planning a backup strategy, refer to Backups

* If branching an application, a ChangeSet is the right tool for the job. Branch an Application

ChangeSets do not include logged data, alarm history, I/O setpoint history, operator actions, or saved HDV pen groups.
The information in this chapter applies to only the application code, including tags, pages, custom drivers, etc.

ChangeSets do not include OEM layers. If your application was built on a layer other than VTScada, then for purposes of distribution, a separate ChangeSet must be created for that OEM application and distributed with your application's ChangeSet file.

ChangeSets and Evaluation Licenses or VTScadaLIGHT licenses:
If the ChangeSet was created under either an evaluation license, or a VTScadaLIGHT license, then it can be used to create a new application when running under a paid license.
It cannot be used to apply changes to an application already running under a paid license.
In short, developers must purchase a development license to do development.

Excepting template ChangeSets, do not store ChangeSet files in the application directory.

The details of what will happen when a ChangeSet is applied will depend on the type of ChangeSet you use - standard or snapshot, and if snapshot, with or without source files. It also matters whether the application runs on one or multiple servers. An incorrect choice may have undesirable results.

If you do development work for another site on an infrequent basis, keep your copy of the application up-to-date with the other site's. The best way to do this is to obtain ChangeSets from that site and apply them to your local copy. If you make changes to your out-of-date copy and then attempt to apply your ChangeSet to the customer's newer application, you run the risk of version conflicts. In the case of such a conflict, always choose to keep the existing version at the customer's site, never the one from your ChangeSet based on the out-of-date application.

To install a ChangeSet, you may either use the advanced menu of the Add Application Wizard, or simply double-click on the ChangeSet file.

ChangeSets and Version Control

ChangeSets contain an application's version history but should never be used as a substitute for version control. Consider the following example:

1. On Monday, you create a ChangeSet of your application.
2. You do development work through the week.
3. On Friday, you use the Apply ChangeSet command in an attempt to roll back to the state of the application as it was on Monday.
4. Nothing happens.

Apply Changes does not mean "over-write", it means "merge". Everything that is in your Monday ChangeSet file is still in Friday's version history, therefore there is nothing to merge. If your goal is to roll back to an earlier state of the application, use the Version Control system. (Version Control) Never attempt to roll back to an earlier version by deleting your application and then installing an older ChangeSet.

See also:Local versus Deployed Changes. If Auto-Deploy has been disabled on your workstation while making the changes that are included in the ChangeSet, then when applied to the destination computer, those changes will exist only in a local branch. Auto-Deploy relates to changes made to the application, not to the making of the ChangeSet.

Standard ChangeSets

These can include a full development history or just the history since a revision file was created. If auto-deploy is disabled at your workstation, you are advised to deploy changes before making a standard ChangeSet. Changes that are not deployed on your workstation will not be deployed on the destination workstation. (Local versus Deployed Changes)

This type of ChangeSet is used for the following tasks:

• Initial installation of an application on a machine, but only if that workstation does not have a network connection to other workstations running that application.
• Applying changes to an existing application, where those changes were made on a workstation that does not have a network connection.
  Changes within the ChangeSet will be merged into the current version.
  Note that one application's ChangeSet cannot be applied to other applications, including clones of the original.
• Sending a copy of the application for technical support.
• Creating a clone (identical copy) of an application to test changes without harming the running application or accidentally distributing your test to other workstations.
  The version history, stored in the ChangeSet, will not be visible unless you set the application property, RepositoryShowCloneHistory to 1. This property must be part of the section, "Layer" rather than "System".
• Application recovery, using a recently created ChangeSet.
  You might choose to create a standard ChangeSet on a regular basis as part of a disaster recovery plan.
  If the application is still running on another server, do not use a ChangeSet to restore the lost workstation. Use "Get from workstation" instead.
  Remember that data is not included in a ChangeSet and must be managed separately.

Limited ChangeSets and Revision Files

When sending updates for a larger application, it can become cumbersome to include the entire version history with each new update. You can limit a ChangeSet to include only the changes that are not already present on the target machine.

Revision files will typically be created on the workstation that the ChangeSet is destined for, not on the machine where the ChangeSet is being created. The point is to find out what's already at the destination before creating the set of changes required to bring that workstation up to date.

Another use is to create a revision file immediately after creating each ChangeSet. (Both are created on the same machine.) When the time comes to send updates to the remote machine, you can use the revision file dating from the last ChangeSet to include and send only changes made since the previous update.

VTScada will compare the version information of the remote computer, as contained within the revision file, to the local version log to choose what new revisions need to be included in the ChangeSet being created.

As a best practice, you should obtain an updated revision file from the remote computer immediately before generating a ChangeSet destined for that computer. The following example illustrates the process, where changes need to be transferred from a development workstation to a remote workstation. The steps would be the same, but on opposite computers if the transfer needed to go the other direction.

Snapshot ChangeSets

These do not include version history. They hold only the current state of development of the application on the machine where the file is created. (Whether the current state includes local or deployed changes is not relevant. What is sent is the current state on that machine.)

Snapshots may or may not include source files, according to your choice. If source files are not included, it will not be possible to edit the pages, widgets or other components on the workstation where the Snapshot is installed.

When a Snapshot is applied to an application, it replaces the current version of the application, rather than being merged into it. Local changes will be lost.

An application distributed as a Snapshot without source files will run as a read-only application. The Idea Studio button will not, and can not, be enabled.

Snapshots are used for the following:

• Installation of OEM layers, where the development work that went into that layer is proprietary knowledge.
• Installation of applications on workstations that are licensed as run-time only.
• Distribute changes to an application on a run-only workstation.
  If local changes exist, they will be lost when the snapshot is applied. This includes operational changes such as disabled alarms.
• Return an application to a earlier state.
  In general, it is better to use the Version Control system for this purpose.
  Do not use a ChangeSet for this purpose if your application runs on multiple servers. Damage to the application on all servers may result.
  

You can install a ChangeSet by double-clicking the file on your desktop or in Windows Explorer™. If VTScada is not running, it will start.
Note that ChangeSets have a distinctive icon to help you distinguish these files from the shortcut to the VTScada executable file.

Troubleshooting:

• If nothing happens when you double-click on a ChangeSet file in Windows explorer, it is likely that some other program has associated itself with this file type. Advanced users may check their Windows Registry settings to remove the following key, then reinstall VTScada to reset the file association and behavior. Proceed with care - damage to your system registry can leave a computer unable to operate.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.changeset]

 

Template ChangeSets

Template ChangeSets are seldom required.

If you have a legacy OEM layer that made use of this technology, please consult with Trihedral Technical Support. It is likely that newer options exist, which will allow you to move away from the use of a Template ChangeSet.

The steps to create a Template ChangeSet are complex and will vary depending on your application and your plans for the ChangeSet. Consult Trihedral Technical Support before attempting to use this feature.