VCS best practice for development vs production & and include Sentry as a toolset

Doug Easterbrook doug at
Thu Feb 1 16:31:43 UTC 2024

don’t know why, but I thought of this notion regarding JSON export and the VCS this morning as a bit of extra info favouring using JSON export regardless if you also use the VCS

If you write code and

- upload to VCS, the code can be incomplete.  Meaning you can have BAD syntax, incomplete code, mismatched end if’s and various other errors in the library.    If you want to automate builds, these code errors are such silent killers that you don’t see them at all.     Unless you’ve implemented something like sentry to capture and relay back errors.

eg the following has at least 3 syntactical errors.  You can check that into the VCS, and you can check it out of the VCS.

If A+#???
  do Meth $cinst.$myMethod (’text)
quit method

the errors for what its worth
#??? -> invalid file variable that is not tokenized or not there, or deleted
do meth. —> not a valid command
’text —> incomplete text string

- it is why we always export our library to JSON.  any syntactical errors are always caught and prevent the export to JSON.    and the reason is that during the omnis export, it reimports the file to test that the code is valid.  if it is not. valid, you get an alert and cant export it till you fix it.

I can’t tell you the number of times that I’ve found syntactical errors with that can now arise with the IDE. (which I love by the way) because code is now typed.

for what its worth.        

Even if people do not want to use the json export as their VCS or with Git, I recommend always exporting your code periodically (I do it with every VCS checkin) just to make sure there are no syntactical errors.

Sentry is another topic —   I highly highly recommend using the tool to capture an omnis errors (we do it by enabling the omnis error handlers and sending any errors and corresponding stack trace that the runtime encountered to us).       Its found issues in code that we thought was perfect (foolish us) but had various edge cases we never thought of.

It lets us fix various silent errors quickly and release a new version, sometimes before people realize that it happened.

Sentry is open source,  you can have them host it, or you can download and host it yourself if you are into privacy and security.

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

> On Jan 31, 2024, at 6:32 AM, Alan Davey <david.a.davey at> wrote:
> Hi Paul,
> If you are able to use JSON export/import for your libraries, why would you
> want to use an Omnis based VCS instead of github, bitbucket, etc.?  Those
> repositories have lots of nice add-ons and hooks to better manage and
> automate your CI/CD pipelines.  My goal is to get away entirely from the
> Omnis VCS at some point so that multiple developers can finally work on the
> same classes at the same time.
> Regards,
> Alan
> On Mon, Jan 29, 2024 at 8:49 PM Paul Mulroney <
> pmulroney at <mailto:pmulroney at>> wrote:
>> Hi Doug,
>> Thanks for your email - another excellent overview of Git and SVN.
>> I should've said "if only we could build an Omnis-based VCS using JSON and
>> git ..."  vcs is a general term, but when I think of the Omnis Version
>> Control System see in my head as all caps.
>> Regards,
>> Paul.

More information about the omnisdev-en mailing list