Probleme mit **FREE und /COPY

[Andreas_Prouza]

Nach einem 50. jährigen Jubiläum ist das auch verständlich :-)

[E305GL]

I.W. handelt es sich um Erweiterungen des kostenlosen VS-Code (Visual Studio Code).
eigentlich wurde meine frage nur ausweichend beantwortet.....???
ich habe nicht gewusst, dass nicht IBM bzw. OS400 PC-, MS-produkte sowie "eigenentwicklungen" als lösungen zulässig sind. früher hat's dafür die rote karte gegeben, oder....

[Andreas_Prouza]

VS-Code ist kein Lizenzprogramm. Ergo sind auch alle Erweiterungen darin kein Lizenzprogramm. Jetzt beantwortet?
Verstehe nicht wofür genau es hier eine rote Karte geben sollte.

[RobertPic]

@GIT
Ich kann mir von jeder Zeile die Infos anzeigen lassen, wer, wann was geändert hat:

692


Ja, ich sehe nicht das Änderungsdatum als eigene Spalte auf einen Blick, sondern muss auf jede Zeile springen.


Will ich wissen, was im Zuge dieser Änderung noch alles angepasst wurde, brauch ich nur den Vergleich für diesen Commit öffnen:

693

Ich weine keine Träne der Date Spalte hinterher.
Mit dem IFS habe ich eine große Vielzahl an Möglichkeiten, die es mit SRC-PF nicht gibt.

Hallo Andreas,

es geht um die historische Informationen - vor der Versionskontrolle - die beim ersten Import verloren gehen. Gekoppelt mit Kommentaren bzw. auskommentierten Zeilen lassen sich auch Rückschlüsse ziehen, was/wann geändert wurde. Natürlich kein Vergleich zu einer echten Versionskontrolle wie GIT oder SVN.

Ich habe schon mal über eine Ex/Importprogramm nachgedacht, welcher mir das tageweise exportiert und jeweils ein COMMIT macht. Aber wenn wir da was angreifen, passiert das i.d.R. meistens um es abzulösen.

[Andreas_Prouza]

Hi Robert,

Mit "historische Informationen" meinst du das Änderungs-Datum je Zeile? Das Datum das eigentlich nur aussagt, dass hier eventuell etwas geändert wurde oder auch nicht und bei gelöschten Zeilen jede Info fehlt?

[RobertPic]

Hi Andreas,

ja genau diese Info. Ist natürlich nichts 100%iges - zusammen mit der Praxis "Zeilen nur auskommentieren" bekommt man aber zumindest Hinweise. Auch mit den Änderungen suchen ab Datum.

Ich ziehe natürlich auch eine echte Versionskontrolle vor, war bei der Suche im Legacy-Code eben auf diese Infos angewiesen um mit dem Datum (falls nix dazu kommentiert ist) und unserer restlichen Doku (Deploymentlog, Projekt und Zeiterfassung) den CR zu der Änderung finden.

Im Vergleich zu den aktuellen Werkzeugen natürlich eine absolute Notlösung - aber trotzdem ein gewisse "Restinformation" die ich/wir nicht gerne verlieren würde.

[Fuerchau]

Wenn man es mit der Source-Control ernst nimmt, so muss man jeden Tag committen, ansonsten sind keine Tagesinformationen vorhanden, sondern nur die Daten des Commit.
Zwischenzeitliche Änderungen sind dann eben auch weg.
Es mag lästig sein, aber es ist halt empfehlenswert, da man schnell mal sehen kann, wie war es denn vorher (gestern, vor einer Woche, ....) um es auch eben mal zurückzudrehen, weil man sich da vertan hatte.
Leider gibts das nicht im RDi. Dafür wird dann schon mal CMOne angetan.

[Andreas_Prouza]

Im RDi gibt's auch GIT. Könnte man sogar mit SRC-PF verwenden.

[AG1965_2]

Naja, wenn man sich die Mühe macht und vor allem die Historie nachvollziehen kann, dann geht das schon.

Ich habe mir die Source-Sicherungen der letzten - ich glaube es waren 12 - Jahre besorgt und unser homegrown Editier-Protokoll habe ich dazu verwendet, den jeweiligen Stand in git zu comitten. Als der damalige User, mit dem damaligen Timestamp.
Da in unserem Protokoll auch das Jira-Ticket drinsteht, habe ich das als commit-Message verwendet und nun sehen wir bei jeder Zeile, wer das wann warum gemacht hat - viel besser als vorher!
Da unser git-Repo auf einem gitlab-Server gehostet wird, kann Jira diese commits sogar finden und verlinkt darauf.

Umgekehrt ginge es auch, mit "git blame" kriege ich die Infos alle auf einmal und könnte die Source mit dem richtigen Änderungsdatum auch wieder in ein Source physical file schreiben.
Aber wie Andreas Prouza so richtig schreibt: wer will das schon?