Newsletters

Version Control

Version Control

There are two primary version control systems in use for the development process. These are:
  • Omnis Studio VCS - which is provided by the vendor and used exclusively for the version control of any Omnis Studio Code
  • GIT - which is used as a version control system for any other project, specifically python, web pages, and C code

GIT Repository

GIT Repository

All code & web pages (other than Omnis Studio) is saved in our GIT repository from git-lab

There is ample documentation on

  • git-lab on line
  • and the general usage of git to make:
    • repositories
    • Pushing changes (similar to Check-in)
    • Pulling revisions (get latest changes for a branch)
    • Making branches (we always have master, current development branch and any a number of specific branches for features)
    • Merging branches

Various Git tools provide ample ways of diff-ing changes in versions, seeing who made the change (blame) etc.

Omnis Studio VCS

Omnis Studio VCS

The features of the Omnis VCS are described in the Omnis Developer Manual. The key ways that we use it are described in the following sections.

Branches

Branches

The Omnis Studio VCS supports branches of code. This is a feature that is NOT TO BE USED at this time because it does not support merging branches. When this merge feature is provided, we will have two code branches: Main and HotFix

The Main is the head branch. It is where all new development is done. It is also the first place you should fix when patching an issue.

HotFix branches are created at the time of release. The latest branch is forked and new development continues in latest while issues that are reported are fixed in HotFix.

Getting Source

Getting Source

When you are ready to get the source code, build a library by starting the Studio development tool, signing in to the VCS and then ‘build updated projects’. Make sure your library status is ‘Unlocked’ for development (locked is used for a release build)

Get Latest Revisions

Get Latest Revisions

To get the latest code to an existing library, click on the ‘Theatre’ icon and then ‘update from VCS’ link. A list of changed components is presented to you. Copy them out ‘read only’ if you do not plan on changing them. Do not fill in the ‘Check Out Notes’

Check the recursive checkbox, and when the Build tree check box appears check it as well. Click OK to begin the get process.

It is possible to build prior revisions of the code based on labels. Labels are applied to each major release and the Build Manager will perform that task when a release is done.

Classes can be deleted or marked deleted in the VCS when they are no longer required or referenced. For that reason, it is recommended on a periodic basis (eg when a major release is completed, or you have finished a project), to check in all code and then rebuild the library.

Comparing Revisions

Comparing Revisions

If you want to compare the current source with a particular revision of the code, select the class comparison tool and select the class that you are interested in the upper window. Select the VCS and the version from the check in history that you want to compare the current code with. This illustrates the importance of the check in notes.

Checking Out

Checking Out

The VCS is a locking version control system. When you are ready to make changes you need to check out (or unlock) the code you want to change. To do this in VCS, find the component you want to change, right click on it, then select ‘Check Out’

On the checkout window, indicate:

  • the reason you are checking out the component. If there is an associated FogBugz case, enter that as in the checkout notes along with a brief synopsis of the activity intended to be worked on.
  • If you are updating from the VCS or testing a component, indicate that you are copying out the components for testing.

Adding Classes

Adding Classes

If you need to add new classes to the code, click the ‘New Class’ option. That will automatically create a new class for you and mark it as ‘locked’ by you. Anything that has a ‘lock’ is a candidate for check in.

The name of the class is to be given a name according to the naming conventions in the coding practices.

If you decide to discard the class before checking it in, simply delete it. If you check it in and discover that you no longer want it or need it, the it must also be deleted from the VCS.

Checking In Changes

Checking In Changes

When you are ready to check in units, either right click on the specific class and check-in or use the ‘Auto Check-in’ option on the window. When you select either, you will be presented with a list of classes you have checked out. Click on the classes that are to be returned to the VCS.

When checking in, make sure that you:

  • put the issue number from FogBugz in the check in notes (if available).
  • add an explanatory comment with the case number
  • indicate the severity of the issue and scope of the change
  • update the version number to match the current release version to indicate when it was fixed.
  • Complete the case number in FogBugz and to indicate its status, mark it complete, ready for testing and put in release notes into FogBugz as well. Ideally, the release notes and the check in notes should be the same.