VCS best practice for development vs production

Doug Easterbrook doug at
Fri Jan 26 16:49:04 UTC 2024

hi Paul.

The right answer is to use a tool that supports true branches and merges for your version control.      The VCS does NOT support branches without workarounds.  

Workarounds like
- using multiple VCS’s (as many have mentioned), and
- a manual process of being really really careful as you check in so that you don’t overlay the wrong class in the wrong repository
- making physical copies of libraries before checkin and checkout and labeling them in some way so you can recover from getting some class you did not want.
- and testing each checkin against that VCS to make sure it works.

never mind all that, in a multi developer environment, I find I spend hours using the code compare of libraries vs VCS and libraries vs backup libraries to make sure I’m not hooped by a bad bit of code. (or a good bit of code thats more advanced than my version can handle).

I find it all just leads to extra effort to make sure we don’t do a silly thing and release something that doesn’t work to the client — and even though I go through many code checks over and over, we still make mistakes.

enter GIT.    we use git for all our server applications to have multiple branches.   There is one repository with everything in it.     it has a production branch, a development branch, a feature XYZ branch (where there is only code changes that pertain to the small feature XYZ), and feature PQR branch (that has different changes for feature PQR)

and if your try to merge features where code has changed in the same file, git is really really good about alerting you where exactly the possible conflicts are and out can merge them together, or ignore the change and pass it back to the developer to sort it out.

in other words
- branches are a native part git
- merging is a native part of git
- conflict identification is a native part of git
- version compare is a native part of git 
- and ‘blame’ is a really good feature so you can see, line by line, who changed  specific areas of code in a file

- git is decentralized which is going to pay us back a lot (I’ll explain at the end of the email)

and there are a number of free GUI applications (like github desktop) or paid ones (like TOWER, which I really like) which graphically show you where you are in the branches so you can pick things other than merge in to the development or main branch.

in other words, your work flow is visible.

We use git for almost everything.  postgres stored procedures, web pages, server code, ansible scripts, documentation, you name it.   best thing to use.   

plus we have a tool called ‘CodeSearch’ (open source) that we use to find where certain things are used across all our code.   so if I’m looking for a variable and the impact of changing its use, meaning, name, we do a code search and it tells is where that variable is used in our python code, javascript code, omnis code, postgres procedures, etc.  VERY USEFUL.

On to Studio.      We use BOTH the VCS and JSON Export.   and I want so bad to drop the VCS completely because of the BENEFITS of using GIT.        Give me any reason to move exclusively git, like a big project, and I’d be there tomorrow.

In addition to the above benefits of GIT, the omnis JSON export will not export if there is bad code in your library.   In other words you can’t export
- things like mismatched if’s/end if’s.   
- code that cannot be parsed.   try put a ‘q’ on a line by itself or have incorrect 'quotes’ in a text string.   you can’t export it. 
- it identifies those crazy ‘ident 0’ items in a window that just get worse over time if you don’t address them.

The code checking is FAR MORE EXTENSIVE ….    which reduces mechanical errors that have been made.

Why do we still use the VCS and why have we not got to JSON export only?

Couple of reasons:

one: the json export is chatty 

Over the course of time, this has become much better.   it is definitely good as an export tool.

two: it misidentifies some classes as changed, when in fact they have not
(addressed in studio 11)

if you do a find and replace of some code that is not marked as checked out by VCS… omnis will change the mod date and internal version number of the object (in some cases).   that means you
- did not change the code
- the VCS doesn’t think you did
- the JSON export looks at different fields than the VCS, so it does think that the class has changed.

In studio 11, you can tell the JSON export to ignore classes where only the mod date has changed, I have not verified that yet as we are at the tail end of studio 10.22 development and hope to be full 11 soon.

Three: changing #Style may cause some chatty change in a checked out class

if you change some component of a style in #styles for mac or windows, and check out the class, then check it back in, omnis backfills the style change into the attributes of the field that use the style.       in other words, while omnis references the field style in the property manager, it also updates any changed properties (like font size, bold, etc) when you check the item out of the VCS.

why?  I don’t know, but I surmise it is because omnis uses that info to determine if you can override the property on a field by field basis when editing the window class.

It causes some additional updates on the json export.  Not the end of the world.   just a little bit of noise.

other than the above, I’m so close to tossing the VCS and using only the JSON export/import.

If I were to use the JSON Export exclusively what would be my procedures

I would suggest this as an approach:

1) in your startup library, I would recommend preventing accidental code changes using this line of code.   it means don’t allow changing libraries unless checked out and forces VCS checkout if you want to change it.     It means no accidental changes to a class.   I would set this REGARDLESS if using the VCS or if using the JSON export.     

I do not like things changing on me rom find /replace or accidental hitting delete buttons — so its SAFE coding.

Calculate $root.$prefs.$alloweditifnotcheckedout as kFalse

2) if you want to change a bit of code

right click on the object, and ‘mark as checked out’.   make your changes, then ‘mark as not checked out’.

Nice part if this with the JSON Export, the changes are made and you see them when you export the library.

3) export to JSON after every change (make changes small and verifiable)

in other words, if you toggle the ‘mark as checked out’ on a few classes, make your changes, test your code, think its all right and set it back to ’not checked out’, then I’d do a JSON export.

If you were using the VCS, you’d probably check in at this point, so the size of the change is manageable and identifiable to a feature.    so no difference

4) use whatever tool you want (command line, guthub desktop, tower) and select all those changed classes.     check them into your LOCAL git repository and give the description of the change something meaningful.

if you were using the VCS, you would also give a meaningful change description, so no difference.

At this point, you have your local changes and are NOT interfering with anybody else.  they can be on a branch, if you want to use that.

5) now we can deal with conflicts

You can PULL other changes and merge them into your code.   assuming nobody else changes base code, you will be fine, you get the changes others have made on the branch your want.

if there is a conflict in the JSON code, you can resolve it.   meaning two people changed the same object, albeit maybe different methods.    for what its worth changing different methods generally do not cause conflicts unless a new instance var is added, but at least you see them.

6) Moving forward, you can pull out all the code on any branch and test it.

if you like the code, it passes automated tests, or what have you, you push things in and merge.

The one thing you can’t do is TROMP on somebody elses code like you can with the VCS where you can force check in a class ‘damn the torpedoes’.      with git, you have to explicitly merge the code, discard the code or stash it.

What would I do?

if you are just one developer, I’d stick with VCS, since you are comfortable.

if you are two developers, using studio 10.2x or 11, I think the JSON export and import is work switching to to handle branching, code verification and all the other reasons I’ve outlined

My plan is JSON EXPORT to GIT exclusively as soon as we get to studio 11.   The only reason I am not doing it right now is that I’m straddling the studio 10.2x and 11 line.

The VCS doesn’t handle it.  

JSON DOES as you can ignore properties that are introduced between omnis versions.   but I want to use all the new gui things in studio 11, which means straddling two versions of omnis is far more complicated than say, straddling studio 5 and 8.  or 8 and 10.

just my two cents.     learning of git process for sure,.     graphic tools like tower or github desktop (or using both) help.   but worthwhile, I think, for the granularity you get on changes and branching.

after years using it for other code development,   its a far better system for tracking multiple versions and releases and backing out changes in case of a screw up.   None of which the VCS offers without a lot of manual stuff.

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

> On Jan 26, 2024, at 1:40 AM, Paul Mulroney <pmulroney at> wrote:
> Hi Everyone,
> Our biggest client has given us some major projects to be done, while at the same time they want to keep sending us maintenance items to fix.  In times past we've been able to arrange it so that the big changes are relatively separate from the production code, so we don't have to worry about introducing bugs into production.  However, it's coming to the place where that is no longer feasible and we are looking at a way to setup two branches - Production and Development.
> The Production "branch" (for want of a better term) is the live system, and maintenance patches are done here.  The Development branch is where we're building the new major work that may be a significant change from the old system.
> We're thinking about two approaches:
> 1. Using two Omnis VCS repositories - Production and Development.  I can see problems with this approach - for example, maintenance changes need to be done in both VCS (double entering code ... not good); when the Development version is ready to deploy, how do we get it into Production, etc.
> 2. Somehow using the JSON conversion tools and git to merge the Development into production.  The process would be something like: Omnis -> JSON -> git merge -> Omnis.  Lots of manual process, and we'd need to be smart about dealing with merge conflicts.  
> I'm sure that other Omnis developers grapple with this issue - what's considered best practice for Omnis source code control when you're working in two environments?
> I would appreciate any insights that people might have with this!
> Regards,
> Paul.
> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."  Brian W. Kernighan
> -- 
> Paul W. Mulroney                                            We Don't Do Simple Pty Ltd 
> pmulroney at       Trading as Logical Developments
>                   ACN 161 009 374 
> Ph: +61 8 9458 3889                                       86 Coolgardie Street
>                                                                         BENTLEY  WA  6102
> _____________________________________________________________
> Manage your list subscriptions at
> Start a new message -> mailto:omnisdev-en at

More information about the omnisdev-en mailing list