Zitat Zitat von dschroeder Beitrag anzeigen
Wenn ich nach Details gefragt habe, wie z.B. "wo bleiben denn die Source-Beschreibungstexte?" hieß es in etwa:
- Die meisten Programmierer sind nicht auf die Texte angewiesen
- Wenn mein Gesamtprojekt so groß ist, dass ich auf die Texte nicht verzichten kann, dann ist mein Gesamtprojekt eben nicht optimal.
Diese Aussagen und noch andere waren der Grund warum ich OBI ins Leben gerufen habe.
Leider heutzutage, wenn ein Tool eine Anforderung nicht erfüllen kann, ist automatisch die Anforderung falsch, ohne jegliche Reflexion ob die Anforderung eventuell sogar eine Bereicherung für das Tool wäre.

OBI ist nicht perfekt. Jedoch können Kundenwünsche schnell und unbürokratisch übernommen werden. Ich glaube sogar es war deine Aussage über die Source-Texte, die mich dazu veranlasst haben dieses Feature zu implementieren.

Was die (IBM) Empfehlungen betrifft ...
Für mich stellt sich die Frage: Möchte/Muss ich in den nächsten Jahren neue Entwickler ins Boot holen.
Wenn ja, welche Anforderungen sind nötig und wieviele Bewerber decken diese ab?
Mit IFS, Git und Vscode habe ich eine Basis mit der sich mehr Entwickler einfangen lassen, als mit SRC-PF & Co.

Nicht nur, dass ich mit diesem Weg mehr Möglichkeiten zur Integration diverser Tools habe (z.B. CI/CD), man wird auch interessanter für Unternehmen und eine Umschulung auf IBM i wäre einfacher zu Argumentieren.


Was das GIT MERGE betrifft, wie gesagt: Du kannst es einstellen wie du es haben möchtest. So auch ...
1. Entwickler A ändert Source ABC.RPG
2. Entwickler B ändert Source ABC.RPG
3. Entwickler A Commited seine Änderung und überträgt diese ins remote Git
4. Entwickler B Commited seine Änderung und möchte ebenfalls überträgen
4.a. Entwickler B bekommt von Git die Info, dass bereits Änderungen durchgeführt wurden und diese vorher übernommen werden müssen
4.b. Entwickler B sieht dann in einer Vergleichs-Ansicht seine Änderungen und die des Entwickler A
4.c. Entwickler B entscheidet welche Änderungen übernommen werden soll bzw. kann den Code in der Vergleichs-Ansicht auch direkt noch anpassen.
4.d. Wenn Entwickler B den MERGE abgeschlossen hat, Commited er den Merge und überträgt die Änderungen ins remote Git

Im Git ist nun alles transparent, wer was geändert und zusammengeführt (Merge) hat.

Arbeiten nun Entwickler A wochenlang an einer Source, die zwischenzeitlich von Entwickler B (wegen eines Hotfix) angepasst wurde, kann Entwickler A sich jederzeit die Änderungen von Entwickler B holen und mergen.
Somit muss Entwickler A nicht bis zur finalen Fertigstellung mit dem Merge warten.

Git kann noch viel mehr. Nicht alles wird benötigt. Dadurch ist Git DAS Versionsverwaltungs-Tool und wird in sehr vielen anderen Tools unterstützt. (JIRA, VSCode, Eclipse, Azure, Slack, Teams, Kubernetes, AWS)