Version Control
As you develop your applications, every change is recorded to a distributed version control system. "Distributed" means that the complete history of changes is shared with all the workstations running the application. You can return to an earlier stage of development at any time by using the commands in the Version Log.
Full access to the version control system is an optional feature that your company may or may not have purchased with your VTScada license. Check the list of features included with your VTScada license in the About VTScada dialog.
The version control system offers far greater flexibility than a simple Undo-Redo. Features include:
- The ability to return directly to any earlier stage of development.
- Because the act of switching to an earlier version is itself logged as a stage in the version control system, you have not "undone" and lost changes to intermediate stages of development but have added one more change to the log.
- You can merge (or then reverse) specific changes from a selected version.
For example, given an application with 20 versions recorded in the version control system, you decide to switch to version 10. You can then choose to merge just the changes made in versions 12, 15 and 18 into version 10 and carry forward from there. (Note: later versions often depend on work done in earlier versions. If you merge the work from a given version, be sure to include all related changes.)
- You can reverse or merge specific changes from a range of versions.
You can select a range of versions, and then select specific changes done across those versions to be reversed or merged.
- VTScada uses a distributed version control system. Version changes can be made by authorized users on any workstation, regardless of whether the primary configuration server is available.
In the version log, entries include both development steps and actions taken within the version control system such as switching to an earlier version. In this context, "reverse" means to undo whatever was recorded in one or more log entries. "Merge" means to take one or more log entries that contain steps that are not part of the current version and make them part of the current version. This could mean either bringing back development work that was removed by a reverse or taking development work that is local on another workstation and making it part of the current version. (In effect, a "deploy" of local changes from another workstation.)
Automatic versus Manual Version Deployment
By default, all version changes are automatically deployed. This is controlled in the "Other" tab of the Edit Properties page of the Application Configuration dialog.
If you switch off the Automatically Deploy option, then you must choose when to Deploy your changes, using the Deploy menu item in the Application Configuration dialog. All local changes will be included when deploying.
You can use the Revert Changes tool only when there are local changes to revert. That is, when the Automatically Deploy option is not selected. The revert changes command will discard all local changes, returning your system to the last Deployed version.
While automatic deploy is on, a variety of actions will cause deployment, including editing a tag, closing the Idea Studio, and doing various tasks within the Idea Studio. If, by chance, an extremely minor change was made and nothing else triggers the automatic deployment, then VTScada will deploy that change after three hours.
When you add, modify or delete user accounts, these actions count as changes to your application and therefore become part of an application's version history.
If a switch to a different version of the application will affect user accounts, you will see a warning, asking if account information should be changed. You can say "Yes" in response to this dialog to apply all changes including those that will affect account information.
Use care when changing versions
If you select "No" only the changes that do not affect user accounts will be applied.
Having selected "Yes" you can still recover those account changes. Do so by merging back in, those revisions in which the account changes were made.
When reversing or merging changes, you can choose to exclude the Accounts.Dynamic from the list of files included in the action.
Security changes are always deployed immediately, regardless of the current setting of Auto-Deploy.
When you apply or deploy a change, VTScada will prompt you for a comment. The title of the dialog will vary according to the type of change being saved.
The version history for any application is likely to become large over time. By making a note of why each change was made, you can create a clear history documenting your application's development. There is no need for the comment to describe what was changed, as the version history will include that. Better to describe the reasons for the change.
Comments are not mandatory in the default configuration of VTScada. If you prefer to make comments mandatory, you can change the minimum length required. To do so, add the application property RepositoryCommentMinLento the Layer section of your Settings.Dynamic file.
After setting a value for the property RepositoryCommentMinLen, users will see a dialog similar to the following if they do not provide the required number of characters.
Mandatory minimums on comments
