Dealing with multiple Omnis 10.22 VCSs

malkishtini at malkishtini at
Wed Jan 4 17:37:42 UTC 2023

Hi Doug,

Thank you so much for your valuable feedback. As usual, I learn a lot from your messages 😊.

I know that Git is the solution to our problem, and we do use Git as our backend repository, so we do have the infrastructure ready for it.
But the unfortunate thing in our Omnis case now, is that we are dealing with newly converted libraries  (converted from O7) and the export to JSON/import is failing because some of the classes have bad code.
Our libraries are big, and they have obsolete classes and bad code, but we can not afford now to go though all classes in all the libraries and clean them up from the bad code...We are still busy with the conversion and testing the converted pieces and preparing for deploying the converted pieces to production sites. 
That's why I'm trying to find a process to automate anything we can do to support branching our code and have different builds.

I have not worked with VCS branching in old versions of Omnis, so I have no idea how that used to work, but I heard that it was not working well anyway.

So, I'll keep trying to find a solution to eliminate/reduce the need for manual interference in the deployment process, as much as possible, using VCS. 

Thank you,

-----Original Message-----
From: omnisdev-en <omnisdev-en-bounces at> On Behalf Of Doug Easterbrook via omnisdev-en
Sent: January 4, 2023 11:53 AM
To: OmnisDev List - English <omnisdev-en at>
Cc: Doug Easterbrook <doug at>
Subject: Re: Dealing with multiple Omnis 10.22 VCSs

hi Mayada:

happy new year to you too.

supposedly, there was branching in the omnis VCS at one time.    In studio 5.x, we never got it to work, but that was years ago.

the studio 8.1 documentation says it might still be available.   The implication is that sys(236) and sys(238) would give you a clue.   Those functions are NOT in studio 10.22, so I suspect native support for branching is GONE from the studio VCS.

Project Branching

In versions prior to Studio 8.1 you could implement branching in Omnis VCS projects. Access to branching in the VCS in Studio 8.1 has been removed from Studio Browser, but support for branching is still available for backwards compatibility. To enable branching, you can add the following member to config.json:

     "vcs": {
         "enableBranching": true

In addition, sys(236) has been added and returns true if VCS branching is enabled. If sys(236) returns false on a branched project, the VCS will display the default branch data. 

so where does that leave you?     maybe you want to think about and try using the JSON export for VCS since GIT supports branching extensively.

and more importantly, it supports MERGING branches.  

Truly, multiple versions in multiple VCS’s are a hard thing to handle in omnis because merging them is a trial by fire process.   If even just two of us want to change the same omnis class with the VCS, only one can have it checked out.  

if a second person wants to make changes, we end up using the class compare a while lot, and that can take a lot of time, plus trying to merge in where the changes are, and then recommitting it to the VCS.

if you have multiple VCS’s, you are going to hurt — trying to merge the class from development, picking up the changes that are in testing, and then moving it to production.  Its not easy to pick and choose the changes.

the JSON export has each class in its own folder.  and then it breaks each method into its own file.  In theory, it allows you commit methods to your vcs in the branch you are working on (in git — it is very easy to change branches).

and the migrate the changes up the branches.

truth be told, I have not gone full out on only using the JSON export at the moment and abandoning the VCS.            right now we are in a hybrid world of VCS and GIT —    and I’ve been using the JSON export for about 5 years and committing to a GIT repository.  Along the way, we’ve been submitting bug and change requests to omnis and they’ve been very good at addressing them.

We are close to jumping to only using JSON Export/Git — its just a matter of finding the right moment.

but, if you want to do branching …. I’d recommend thinking about the JSON export .. and playing with it.

now, there are free tools like github desktop that let you visualize your branches and who made the changes.   I use tower (a paid tool) as I really like it.

and there are free servers like gitlab (free), than you can also use to create processes that will build libraries each time something is checked in.

so, if you are going for automation, branching, building things automatically, think
- using JSON export/Import
- using gitlab and its automations

I know others are doing auto builds with tools like jenkins and gitlab, so hopefully tey might jump in with their experiences.

I just don’t think the VCS to manage multiple repositories would have a long life and will cause you grief since it is not designed to do that.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at
Phone (403) 650-1978

> On Jan 4, 2023, at 8:10 AM, malkishtini at wrote:
> Hello all,
> Happy new Year everyone!
> We have a need to maintain different code versions, which means we 
> need to have different VCSs, Dev, QA and production.
> We are trying to find a way to automate building the QA and production 
> VCSs from Dev VCS based on certain criteria.
> We use Omnis VCS (studio 10.22) and PostgreSQL database.
> I would like to see if others have dealt with this scenario (deploying 
> different versions of code) before and what solutions they use to 
> achieve it.
> We are trying to build a new process, so I'm looking for ideas and 
> suggestions.
> As usual, all your ideas and feedback are welcomed and highly appreciated.
> Thank you and best regards,
> Mayada
> _____________________________________________________________
> Manage your list subscriptions at Start a 
> new message -> mailto:omnisdev-en at

Manage your list subscriptions at Start a new message -> mailto:omnisdev-en at 

More information about the omnisdev-en mailing list