Dealing with multiple Omnis 10.22 VCSs

Thu Jan 5 15:06:17 UTC 2023

Hi Doug,

You didn’t give me a grief; in fact, you pushed me to dedicate few hours yesterday to test the export myself.

I started with one of our big libraries and I analysed the errors that I got from the export to JSON.

Almost 500 converted report classes failed to export, I know that almost all our converted reports need to be modified in Studio to run properly and that explains why they fail to export. Studio report engine and designer work differently than in classic.

I had to delete all the reports from the library and then rerun the export again, the second time I got less errors that I was able to go through some of them to understand them, most of the issues were related to using wrong variable names. 

The errors I got from the export tool,  were a great analysis to our code, and I might plan to continue using it to fix issues in our code even if we are not using GIT.

The import did finish with a bunch of errors and warnings, then when I tried to import the library.json, the import failed immediately with the same errors and warnings that I got from the export. 

I learned yesterday from that process, and I got an idea of what kind of a job is waiting for us. The big issue that we need to solve, to be able to get our code to GIT, is the “report classes”, the other errors can easily be fixed.  

For the short term, fixing all reports in all libraries is not feasible to us, but we’ll hopefully get there once we finish converting the entire app and we can say that we are O7 free 😊.

Thank you very much for your advice and have a good day,

Mayada 

From: Doug Easterbrook <doug at artsman.com> 
Sent: January 4, 2023 2:29 PM
To: Mayada Al-Kishtini <malkishtini at gmail.com>
Cc: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
Subject: Re: Dealing with multiple Omnis 10.22 VCSs

hi Mayada.

so, here’s a conundrum for you.

you mention you can’t use the JSON export because there is ‘bad code’. but you don’t want to fix that bad code’ since that takes time.

I understand your concern.    you may want to re-evaluate that thought because ‘bad code’ = mistakes and maybe those are ticking time bombs in your old code.

sadly the VCS lets you check in bad code, I wish it didn’t.      the JSON export will tell you when notation is wrong, end if’s are missing, windows have extra object ‘0’s, missing methods, and that sort of stuff.  

as A side note, I’m also finding chroma coding of code really great in the code editor and find and replace windows — because I quickly see there I forgot to put a $ in from of a method many years ago .. and that shows up things that never executed.     That got me recently.    trying to find a bug — and it had been there for a decade or more, un-noticed.   Just had to fix the method call.

please, please don’t ever let me give you grief over how you want to manage your application.     I just really like how json and the editor point out ot me where I’ve been a bad coding dude.

good luck, however you go at it.

Doug Easterbrook

Arts Management Systems Ltd.

mailto:doug at artsman.com

http://www.artsman.com

Phone (403) 650-1978

On Jan 4, 2023, at 9:37 AM, <malkishtini at gmail.com <mailto:malkishtini at gmail.com> > <malkishtini at gmail.com <mailto:malkishtini at gmail.com> > wrote:

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,
Mayada

-----Original Message-----
From: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com <mailto:omnisdev-en-bounces at lists.omnis-dev.com> > On Behalf Of Doug Easterbrook via omnisdev-en
Sent: January 4, 2023 11:53 AM
To: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com> >
Cc: Doug Easterbrook <doug at artsman.com <mailto:doug at artsman.com> >
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 artsman.com
http://www.artsman.com
Phone (403) 650-1978

On Jan 4, 2023, at 8:10 AM, malkishtini at gmail.com <mailto:malkishtini at gmail.com>  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 https://lists.omnis-dev.com Start a 
new message -> mailto:omnisdev-en at lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at https://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 