Project Versioning

Each project can have two distinct versions at once: the Staging version and the Published version. By default, a new project is configured to be in Auto publish mode, which means that the two versions are always identical. However, if you change a project to be in Manual publish mode, then you can explicitly publish a project in the Designer.

Published vs Staging

The general idea between having a published version and a staging version is to allow you to save a project, and then test out the changes before "publishing" those changes to a production environment. Under normal conditions, Vision module clients run the published version of a project. However, by launching a client in a special mode (from the Designer or from the Config section of the Gateway), you can launch a client that runs the staging version of that project. This staging client will receive updates on every save, where the production clients receive updates only on publish. This lets you test out your changes to the project in an actual client, which is more realistic than the Designer's preview mode.

Not all aspects that comprise a project use this system. It is primarily intended for systems such as the Vision module's clients. Features that run persistently on the Gateway, such as SQLTags, the SQL Bridge's Transaction Groups, and Gateway-side scripting always run the most recently saved changes (the Staging version). Since these features by definition must run in exactly one place, they cannot be effectively "tested out" by simultaneously running a staging version alongside a published version.

Project Versioning  and History

Each project keeps a log of recent changes. These include both saves and publishes. Every save increments a number called the "edit count" for the project, which can be used like a serial number. The user, time, affected resources, and a commit message (see below) are logged as well.

Commit Messages

A project may be configured to prompt the user making changes to describe those changes, either on every publish event, or on every save and publish event. These messages, called commit messages, are used to describe the changes that have been made to the project. By inspecting the project's history and reading these commit messages, you can learn what changes have been made to the project, for what reason, and by whom.

Rollback

In the Designer, a project can be rolled back to one of the last 10 saves by choosing File > Rollback. The rollback only applies to the project resources, and not to global resources such as shared scripts and alarm pipelines.

See also:

Project General Properties