Zensur bei CodeTyphon

Für sonstige Unterhaltungen, welche nicht direkt mit Lazarus zu tun haben
wp_xyz
Beiträge: 3251
Registriert: Fr 8. Apr 2011, 09:01

Re: Zensur bei CodeTyphon

Beitrag von wp_xyz »

Ich kann mir nicht vorstellen, dass sie viel am lazarus-Code fixen. Denn das Problem, dass sich "ein Entwickler hinsetzen und praktisch den gesamten Code abgleichen" muss, haben sie ja auch. Ich denke, sie nehmen den Lazarus-Code 1:1 und lassen nur ihr Tool drüber laufen, das das Wort "Lazarus" durch "PilotLogic" oder "CodeTyphon" ersetzt, die Dateiendungen austauscht usw. Nur die wenigen eigenen Units werden gepflegt.

Warf
Beiträge: 1424
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: MacOS | Win 10 | Linux
CPU-Target: x86_64
Wohnort: Aachen

Re: Zensur bei CodeTyphon

Beitrag von Warf »

Naja, zugegeben ich weiß nicht so sehr viel über SVN, aber über git lässt sich sowas extrem einfach handlen. Git kann das umbenennen von Dateien tracken und mit vernünftigen Merge tools ist das ja grundsätzlich kein problem. Sagen wir mal sie mergen den aktuellen Lazarus trunk in ihr git. Dann kann git automatisch erkennen 1. welche commits bereits schon drin sind, 2. in welche dateien die änderungen gehen falls dateien umbenannt wurde, und 3. halbewegs automatisch ihre änderungen mit den neuen Trunk änderungen.

Auf der Arbeit verwenden wir ein Open-Source projekt, das wir um bestimmte funktionalitäten erweitern. Alle paar monate mergen wir dann gegen das original projekt um die neusten änderungen zu bekommen, das ist normalerweise c.a. 30 minuten aufwand. Wenn wir einen Bug finden der nicht von unserem eigenen Code kommt, kann ich für gewöhnlich einfach das folgende machen:
1. Github projekt Forken
2. unser projekt im git als remote hinzufügen
3. git cherry-pick für die commits die bugs fixen
4. Pull-Request stellen.
Der technische Teil davon ist normalerweise keine 10 minuten arbeit (beim PR muss man natürlich einen Text schreiben, der muss dann auch sauber sein, denn immerhin representiere ich damit ja meinen arbeitgeber, und und und, das kann dann nochmal ein bisschen dauern).

Wenn ich die änderungen dann zwischen meinem projekt und dem original sehen will, füge ich einfach das original im git als remote hinzu, mach dann sowas wie "git diff upstream" und sehe alle änderungen. Wenn ich alle eigenen dateien weglasse (also alle dateien die gar nicht im original projekt vorkommen), ists meist sehr übersichtlich. Grade wenn man das original projekt kennt, kann man das nutzen um sich super reinzuarbeiten, da man sich nur die abweichungen vom orignal ansehen kann. Man kann sich auch z.b. alle commits anzeigen lasse die nicht im original vorkommen, und durch die commit beschreibung bekommt man normalerweise auch ein gutes bild davon was wo gemacht wurde. Findet man was interessantes kann man dann einfach mit nem cherry-pick sich den commit nehmen.

Einfach nur den Source-Code hingeworfen zu bekommen ohne 1. originale VCS infos (also die infos auf welchem stand vom trunk das eigentlich ist) und 2. Commits über änderungen, ist schon das mit abstand aufwendigste was man machen kann. Und ich denke mal das sie intern ein VCS benutzen, die Infos sind also da, PL entscheidet sich also so zu sagen es den Lazarus entwicklern schwerer zu machen. Sie müssen die Änderungen ja eh publik machen, also spricht nix dagegen das sie ihren code einfach auf Github oder Sourceforge hosten. Es ist ja auch eine aktive Entscheidung etwas nicht zu machen, vor allem wenn es nicht mehr aufwand ist

Antworten