Re: Best practices for working with GIT

My experience with git in a linux environment (java) was painful, it was
all open source tools other developers had bolted together, that at various
versions had once worked together but then didn't... Spent a couple weeks
of time recovering a large amount of code. I would stick with a proven and
supported vendor tool. Even then, I would worry about supporting many years
of development with ever evolving (or disappearing) tools. Thankfully that
project ended for me.

Jim Franz

On Fri, Sep 19, 2025 at 2:26 PM Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
wrote:

Merlin was created for just that situation. Only real problem is you need
a Linux system to run the most important parts and the combination of the
software cost and extra partition (not to mention the admin ability) makes
it a tough decision.


Jim Oberholtzer
Agile Technology Architects

On Sep 19, 2025, at 1:15 PM, Sam_L <lennon_s_j@xxxxxxxxxxx> wrote:

I know just enough about Git to be dangerous. I've always had a vendor

supplied SCM (Source Control Management) product, which not only did source
control but also did deployment. Git will not do your deployment (to the
best of my knowledge) and that's something to consider.

There is probably open source software that could be configured to do

your deployment. But I think you should seriously look at a vendor package.

Sam

-----------------------------
message: 2
date: Thu, 18 Sep 2025 08:56:39 +0000
from: Martijn van Breden <m.vanbreden@xxxxxxxxxxxxxxxxxxxxxxxxxx>
subject: Best practices for working with GIT
Hi all,
We're currently investigating how we can implement git (via eGit) in

our workflow. There are so many possibilities that we're getting a bit
lost.

Just to elaborate on our current situation
We are an ISV with a homegrown browser based software application

integrating ERP and finance and some production, service and warehouse
management applications, so it's pretty broad. We have customers ranging
in size from a handful of users to several hundreds. For most of our
customers we have customized code to meet their specific goals. Some of
them have so much customization on older versions that they will probably
not move to our newest version in the near future.

Our code resides in several libraries in a library list that is

established when the user logs on. Besides the libraries we have several
directories containing the front end GUI for the application. Via a
directorylist similar to the LIBL we can add customization and DTAP layers
to the directory list. The directory list is scanned for scripts just as
the libary list is used to determine which object should be used.

At a glance the LIBL looks basically like this.
CUSTPGMDEV - developtment customized application programs CUSTSRVDEV -

developtment customized service programs [CUSTPGMTST - test customized
application programs] [CUSTSRVTST - test customized service programs]
[CUSTPGMACC - acceptance customized application programs] [CUSTSRVACC -
acceptance customized service programs] CUSTPGMPRD - customized application
programs CUSTSRVPRD - customized service programs STDPGM - standard
application programs STDSRV - standard service programs STDFUNC - standard
functions (never customized) CUSTDATA - customer data

Customization libraries only contain sources and objects that are

modified or supplemental to the standard application, so it is a subset of
the application. Not in all cases both the test and acceptance layers are
present.

For directories we have a similar structure with a standard directory

and customization directories. The substructures of all directories are
equal.

/maindir/custgui
/maindir/stdgui
the customization layer is again modiefied or supplemental to the

standard layer.

On our cloud partitions we have several dozens of cutomers working with

the same standard base libraries and directories each with their own
customization layer on top of them.

Th number of RPG sources in the STDPGM is well over 8000 to give an

indication of the size of the application.

My questions are:
1 What would be the best practices to run this situation under Git

source control in RDi (with eGit).

2 What would be a decent structure for the git repos? A branch per

library and/or directory or something else?

3 How can (and should) we work with personal developer libraries and

directories?

4 Should we i.e. be combining standard and customized source to a

single customer library/directory and would this affect performance and
memory usage (since the number of instances of a program increases)

5 How can we improve the initial load time for source members in RDI
6 Can we do an automatic push (to a source member) and compile on save.

Can we influence the target library for the compile?

7 What is the best practice to incorporate our custom compile command

with eGit in RDI?

8 What is the preferred way of interaction between i Projects and eGit?
I hope some of you have far more experience than we have and can help

us further on this topic.

Kind regards,
Martijn van Breden
lead software architect

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.