Version Control
Every step of application development is recorded to VTScada's version control system. 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 instead, have added a new change to the log.
- Having reversed the work of several development steps, you can then merge back some or all of those steps.
- You can reverse or merge changes from a range of versions.
- You can view the version log of every connected workstation running your application.
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" and "merge" mean the following:
Reverse
To remove changes recorded in one or more version log entries.
Merge
To take one or more log entries that were reversed and are not part of the current version and make them part of the current version. This can also mean taking development work that is local on another workstation and making it part of the current version.
Automatic versus Manual Version Deployment
By default, all version changes are deployed automatically. 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, changing property settings, and more.
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. There is no such thing as a "Local" version of security settings.
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