Thanks Manu and Richard for the shout out.
I'm not going to compete with SJ - and hey Susan, long time no see and hope all is good is your world! - but if you specifically want to 'go git' the trick is to think about how to make all the necessary assets to reconstruct or refresh a working environment into source code. That means not only what you traditionally think of as source (e.g. UniBasic, python, paragraphs etc.) but also table definitions, index information - in short, anything your system needs if you are including reporting, selects etc.
Think DDL.
So yes, table defs are a start, as are parameter items and other definitions. Remember that GIT uses a merge model, and may occasionally hit up against merge conflicts unless you have complete control over that, and so you need definition formats that (a) developers can understand when presented with a conflict to resolve and (b) aren't going to cause git to get confused and start adding in lines that would, for example, throw out a field ordering. As an example I've used INI file format for server side parameter items for years for just that kind of reason. You want everything to read as text.
More fun is to consider the workflow you are going to be using. Do you have multiple developers working on the same source account, or does each one have a separate account/repository/instance? If the former, how are you going to manage your add and commit workflow so everything is clean and represents a complete state. Oh, and testing. GIT rewrites your code, so you absolutely need to think in terms of testing to make sure it doesn't merrily break something when it merges.
Lots to think about.
As you may gather I have helped a number of customers along that path... but every site is different. That's what makes life fun :)
Brian
------------------------------
Brian Leach
Director
Brian Leach Consulting
Chipping Norton GB
------------------------------
Original Message:
Sent: 02-09-2024 20:28
From: Gil Steidle
Subject: Source Control help
We would like to put a UniVerse account (all files, VOC, BP, CUSTOMER...) under source control, we use GIT currently for other software projects.
Has anyone been able to successfully do this?
Our strategy in our development account was to convert all files into folders (type 19). But the VOC file and Dictionary files (I-types) have problems with being a folder.
Is there a way to elegantly put all files in a UniVerse account under GIT source control management? Or are we just beating our heads against a wall?
The closest we've come to success is when we created "mirrored" files for the VOC and Dictionaries that were folders and used light-weight triggers to update them when the production (hashed) files were updated. That worked fine and GIT saw changes in those mirror files.
But we then ran into an issue with the GIT and the .gitinclude file configuration. We only want to the show changes in our mirrored files. GIT was adamant about showing differences in all files even the hashes files and we don't want that.
Please let us know what/how you have implemented source control that would be compatible with GIT.
We are using UniVerse on Windows.
Thanks!
------------------------------
Gil Steidle
Developer
DDI System Inc
------------------------------