GIT-Workflow vs. SVN-Workflow

Für allgemeine Fragen zur Programmierung, welche nicht! direkt mit Lazarus zu tun haben.
Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

GIT-Workflow vs. SVN-Workflow

Beitrag von m.fuchs »

Warf hat geschrieben:Ich werd nie verstehen wie man sich freiwillig SVN statt git antun kann, klar ist git zu anfangs komplizierter, aber hat halt auch deutlich bessere features, z.b. das branches nicht einfach nur unterordner sind, sondern ein echtes konzept sind und von git als solches erkannt werden...

Ganz einfach, ich habe beides ausprobiert und miteinander verglichen. SVN macht das was ich möchte, GIT fehlen entscheidene Features und es hat keinerlei Vorteil für meine Arbeitsweise.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Suche Möglichkeiten, um ein Programm zu veröffentlichen

Beitrag von Warf »

m.fuchs hat geschrieben:Ganz einfach, ich habe beides ausprobiert und miteinander verglichen. SVN macht das was ich möchte, GIT fehlen entscheidene Features und es hat keinerlei Vorteil für meine Arbeitsweise.

Und lass mich raten, bei deinem vergleich hast du den selben workflow verglichen oder? Wenn man Git wie SVN benutzt, hat es keinerlei vorteile. Git ist das schlechtere SVN, das sagt aber nix darüber aus ob es ein besseres VCS ist.

Ich mein klar, du hast mit dem thread den du hier verlinkt hast einen use-case gefunden in dem SVN was kann was im git design so nicht möglich ist. Allerdings muss man dazu sagen das dem nur so ist wenn man gänzlich unterschiedliche code basen vergleichen will. Ich hatte deine Bewehgründe damals nicht so ganz verstanden, aber sagen wir mal du hast 3 Entwickler die alle von einem gemeinsamen repo ihren code geforkt haben und du willst jetzt vergleichen wer was gemacht hat. Dann fügst du bei Git einfach für jedes der 4 repos (3 entwickler repo + main repo) einen remote ein, und fetchst die. Die commits die bei allen identisch sind, sind geshared und verbrauchen keinen zusätzlichen speicher.
D.h. SVN hat hier nur einen Vorteil wenn die code basen komplett unterschiedlich sind, und in dem Fall ist dann die Frage: warum willst du sie vergleichen?

Und nur mal um das in den raum zu werfen, ein git clone vom LLVM repository dauert 2 minuten und enthält alle branches und tags und ist 1 GB groß. Den checkout vom SVN trunk hab ich nach 2 stunden!! abgebrochen und da war er auch fast 1 GB groß.
Mit SVN kann man also damit rechnen das man etwa einen faktor 60-100 mehr an Zeit aufwenden muss einfach nur weil es so viel länger braucht für alles

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von m.fuchs »

Ich habe mal ein neues Thema dafür aufgemacht, weil es sonst zu Off-Topic wird.

Es mag durchaus sein, dass mir da immer noch das Verständnis fehlt warum es GIT sein muss. Auch wenn ich denke, dass mehrere Versuche damit warm zu werden ausreichen sollten. Aber so ein bisschen über den Tellerrand schauen kann ja nicht schaden.

Warf hat geschrieben:
m.fuchs hat geschrieben:Ganz einfach, ich habe beides ausprobiert und miteinander verglichen. SVN macht das was ich möchte, GIT fehlen entscheidene Features und es hat keinerlei Vorteil für meine Arbeitsweise.

Und lass mich raten, bei deinem vergleich hast du den selben workflow verglichen oder? Wenn man Git wie SVN benutzt, hat es keinerlei vorteile. Git ist das schlechtere SVN, das sagt aber nix darüber aus ob es ein besseres VCS ist.

Natürlich, ich wüsste nicht warum ich meine Arbeitsweise an ein Tool anpassen sollte. Außer natürlich das neue Tool und die neue Arbeitsweise bieten mir einen Vorteil gegenüber meiner aktuellen Lösung. Ich habe diesen Vorteil jedoch bisher nicht gefunden.

Warf hat geschrieben:Ich mein klar, du hast mit dem thread den du hier verlinkt hast einen use-case gefunden in dem SVN was kann was im git design so nicht möglich ist. Allerdings muss man dazu sagen das dem nur so ist wenn man gänzlich unterschiedliche code basen vergleichen will. Ich hatte deine Bewehgründe damals nicht so ganz verstanden, aber sagen wir mal du hast 3 Entwickler die alle von einem gemeinsamen repo ihren code geforkt haben und du willst jetzt vergleichen wer was gemacht hat. Dann fügst du bei Git einfach für jedes der 4 repos (3 entwickler repo + main repo) einen remote ein, und fetchst die. Die commits die bei allen identisch sind, sind geshared und verbrauchen keinen zusätzlichen speicher.
D.h. SVN hat hier nur einen Vorteil wenn die code basen komplett unterschiedlich sind, und in dem Fall ist dann die Frage: warum willst du sie vergleichen?

Also die Aufgabenstellung ist klar. Ich leite die Entwicklungsabteilung und will auf einen Blick sehen können, wenn wer was gemacht hat. Sprich: Minion 1 fummelt an einer File A im Projekt Todesstern rum und committed. Dann brauche ich in kurzer Zeit eine Benachrichtigung dass er das gemacht hat. Ich kann mir dann nämlich überlegen, ob das irgendwelchen Impact hat, den ich mir mit ihm noch einmal ansehen muss.

Warf hat geschrieben:Und nur mal um das in den raum zu werfen, ein git clone vom LLVM repository dauert 2 minuten und enthält alle branches und tags und ist 1 GB groß. Den checkout vom SVN trunk hab ich nach 2 stunden!! abgebrochen und da war er auch fast 1 GB groß. Mit SVN kann man also damit rechnen das man etwa einen faktor 60-100 mehr an Zeit aufwenden muss einfach nur weil es so viel länger braucht für alles

Das ist dann durchaus ein Vorteil sein, wenn man eine schmale Leitung hat. Ebenso wie die Möglichkeit einen Offline-Commit zu machen. Aber für meine Arbeitsweise spielen diese beiden Features keine Rolle. Und dann ist die Frage: was bleibt von den Vorteilen von GIT?

Dann möchte ich die mal aus dem anderen Thread zitieren:
Warf hat geschrieben:Da muss ich jetzt mal meinen senf dazu geben. An sich ist git nicht gut. Es gehört zum Git Flow Commits, und damit arbeitsinformationen, zu löschen (z.B. Rebase), was praktisch das komplette gegenteil von dem ist was Git eigentlich tun sollte. An sich eigentlich ein Ausschlusskriterium für ein Versionskontrollsystem.

Und damit ist es eigentlich schon draußen, da ist mir das Risiko zu hoch dass irgendjemand was kaputt macht.

Und ein weiteres Zitat:
Warf hat geschrieben:Der hauptgrund warum ich so viel git verwende ist das es einfach jeder Verwendet

Das wiederum ist (für mich) eben gar kein Argument.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Suche Möglichkeiten, um ein Programm zu veröffentlichen

Beitrag von m.fuchs »

Warf hat geschrieben:Und nur mal um das in den raum zu werfen, ein git clone vom LLVM repository dauert 2 minuten und enthält alle branches und tags und ist 1 GB groß. Den checkout vom SVN trunk hab ich nach 2 stunden!! abgebrochen und da war er auch fast 1 GB groß.
Mit SVN kann man also damit rechnen das man etwa einen faktor 60-100 mehr an Zeit aufwenden muss einfach nur weil es so viel länger braucht für alles

Hängt aber sicher auch von anderen Faktoren (Server, Anbindung, etc.) ab. Hab gerade mal testweise OpenOffice per SVN ausgecheckt. 1,8 GiB in 13 Minuten. Finde ich ok.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von af0815 »

Bei GIT sollte man sich mal den Workflow überlegen.

https://www.atlassian.com/de/git/tutori ... -workflows
https://buddy.works/blog/5-types-of-git-workflows

Im Gegensatz zu SVN der einem da etwas weniger Freiheit lässt und auch den Workflow großteils vorgibt (IMHO) sollte man sich bei GIT dazu was überlegen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1430
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von fliegermichl »

Als einen nicht ganz unwesentlichen Vorteil von git empfinde ich die Tatsache, daß jede Kopie des Repos, sämtliche Informationen beinhaltet. Egal ob also ein Server abraucht oder mein Laptop unterwegs. Ich kann aus jeder Kopie alles wiederherstellen.

Ich934
Lazarusforum e. V.
Beiträge: 316
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von Ich934 »

Naja eigentlich muss das jeder selber wissen, mit welchen Werkzeug er am besten zurecht kommt. ;-)

Ich nutze Git und ich finde das gut und prima. Ich habe sehr lange mit SVN gearbeitet und bin dann zu git gewechselt und bereue es nicht. Auch wenn ich meistens alleine entwickel arbeite ich übrigens nach GitFlow. Das ist genau das System, das ich gut finde und das mir eine saubere und logische Struktur gibt. Aber wie gesagt meine Ansicht.

Dazu dann noch den Vorteil, immer alles zu haben usw. kommt noch dazu.
Tipp für PostgreSQL: www.pg-forum.de

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von Warf »

m.fuchs hat geschrieben:Ich habe mal ein neues Thema dafür aufgemacht, weil es sonst zu Off-Topic wird.

Es mag durchaus sein, dass mir da immer noch das Verständnis fehlt warum es GIT sein muss. Auch wenn ich denke, dass mehrere Versuche damit warm zu werden ausreichen sollten. Aber so ein bisschen über den Tellerrand schauen kann ja nicht schaden.

Super Idee das in einen eigenen Thread zu verlagern

m.fuchs hat geschrieben:Also die Aufgabenstellung ist klar. Ich leite die Entwicklungsabteilung und will auf einen Blick sehen können, wenn wer was gemacht hat. Sprich: Minion 1 fummelt an einer File A im Projekt Todesstern rum und committed. Dann brauche ich in kurzer Zeit eine Benachrichtigung dass er das gemacht hat. Ich kann mir dann nämlich überlegen, ob das irgendwelchen Impact hat, den ich mir mit ihm noch einmal ansehen muss.


Ja das kann git nicht Clientseitig, das ist aber by design. Die Idee ist das für alles was über die normale VCS funktion hinaus geht man auf dem server weitere tools bereitstellen muss. Z.B. GitLab. GitLab integriert dann den Git Workflow mit solchen tools.
Ich erzähl mal kurz wie das bei mir auf der Arbeit läuft, wo wir mit GitLab arbeiten. Für alles was wir machen müssen machen wir Issues (tickets) auf. Wenn sich jetzt Minion 1 hinsetzt und ein feature bearbeitet, weist der sich selbst erst mal das Issue zu, damit jeder weis das die Aufgabe vergeben ist, und erstellt einen neuen branch in git (im gegensatz zu SVN hat das keinen overhead). Auf diesem branch fummelt er dann rum, commited wie er lustig ist und pusht dann irgendwann.
Mit dem push kann man auch direkt einen Merge-Request für das entsprechende Feature aufmachen, in dem beschreibt man dann in 2-3 zeilen was der MR macht und schreibt sowas wie "fixes ISSUE" oder so rein, dann wird beim Merge auch direkt das Issue geschlossen.
Solang der MR noch nicht fertig ist steht der auf "WIP", dann kann man ihn nicht mergen und es werden keine benachrichtigungen verteilt. Wenn man mit dem MR fertig ist nimmt man das WIP weg und dann ist er offen für Review.
Beim review kann der Reviewer einfach auf den MR gehen und bekommt dann eine Liste mit allen commits, sowie das diff zum master angezeigt. Man kann dann allgemeine kommentare schreiben oder in den Code gehen und auf eine bestimmte Zeile klicken und da dann was dran schreiben.
Der ersteller des MR's bekommt dann benachrichtigungen (z.b. Mails) für jedes kommentar, und kann sich dann hinsetzten das zu ändern. Wenn er das gemacht hat kommentiert er unter den ursprungskommentaren und der Reviewer bekommt eine Notification. Der reviewer wiederum kann dann sich die änderungen seit dem letzten Review anschauen, und kann seine "Diskussionen" die er gestartet hat entweder schließen, neue kommentare dran hängen oder zu seinen vorrigen kommentaren was hinzufügen.

Sobald sich Reviewer und Minion einig sind, oder so sehr hassen das sie nicht mehr miteinander reden, kann der Merge dann durchgeführt werden (alles über GitLab, der Reviewer braucht das projekt nicht lokal zu haben) und das feature landet auf dem Master branch.
Wenn bei der Diskussion neue sachen aufgekommen sind macht man dafür neue Issues auf und das ganze Spiel fängt von vorne an. Der Master branch sollte dabei dann eh protected sein, das man nur über Merges damit interagieren kann und niemand direkt drauf pusht.

Das ganze kann man dann auch noch so einrichten das jeder MR mindestens N reviews braucht (bei kleineren projekten meistens einen, bei größeren auch gerne mal 2 unabhängige reviews), mit klar verteilten rollen, die der Firmenstruktur entsprechen.

Um jetzt auf deine Situation zurückzukommen, um zu sehen was die Minions gemacht haben kann man also einfach auf GitLab gehen, auf die entsprechenden Projekte und auf Merge-Requests. Oder man stellt sich in GitLab notifications ein, dann bekommt man ne Mail sobald ein MR von WIP genommen wird.

Allein auf grund des massiven overheads von SVN branches macht ein solches vorgehen unter SVN keinen Sinn. Für 2-3 Commits einen eigenen branch zu erzeugen bedeutet halt den kompletten Ordner zu kopieren. Bei einem Projekt wie LLVM also knapp 1 GB.

m.fuchs hat geschrieben:Das ist dann durchaus ein Vorteil sein, wenn man eine schmale Leitung hat. Ebenso wie die Möglichkeit einen Offline-Commit zu machen. Aber für meine Arbeitsweise spielen diese beiden Features keine Rolle. Und dann ist die Frage: was bleibt von den Vorteilen von GIT?


Da du alle informationen lokal hast, und nicht wie bei SVN nur den aktuellen branch und die aktuelle revision, kannst du problemlos dein gesammtes repo navigieren, wenn ein git log mache, sehe ich genau welche branches auf welchem punkt sind, ich kann z.b. sehen mein aktueller branch baut auf dem branch xyz auf, welcher 4 commits von master entfernt ist.
Generell hat git einfach mehr informationen zur verfügung. Der Git-Graph (git log --graph) zeigt dir an wann gebrancht wurde und wann gemerged wurde. Das kommt natürlich auch bei Merges zugute:
Auf der Arbeit entwickeln wir mit Forks einer Open-Source software, wenn jetzt neue features für die Original version (ich nenn sie einfach mal upstream) hinzu kommen, fetche ich den remote (also lade die daten im aktuellen repo runter ohne ein neues repo dafür zu erstellen/auszuchecken) und kann dann einen merge gegen machen. Git an dieser stelle erkenn die commits die zwischen beiden versionen geteilt werden, muss also nur versuchen die dateien zu mergen die jeder von uns separat angepackt hat.
Nicht nur das, wenn in einer der Software dateien umbenannt wurden, erkennt git das auch vollautomatisch und bezieht diese infos dann in den merge mit ein. Wobei ich nicht weiß ob das in SVN mittlerweile auch drin ist, als ichs benutzt hab war das noch nicht drin (ist aber auch ewig her).
Außerdem kann git erkennen wenn du vorher bereits schonmal gegen gieses repo gemerged hast und macht damit subsequente merges einfacher

m.fuchs hat geschrieben:Und damit ist es eigentlich schon draußen, da ist mir das Risiko zu hoch dass irgendjemand was kaputt macht.

Während ich hinter diesem hauptkritikpunkt zwar im grunde immernoch stehe, hatte ich zu dieser zeit noch nicht so sehr mit branches und GitLab gearbeitet. So kann man in GitLab branches protecten (wie z.b. den master branch) dann kann man keine history rewrites mehr drauf machen. Man kann (und sollte) das nur auf den eigenen feature branches machen. Im worst case, wenn man nicht aufpasst, kann man da schlimmsten falls nur seine gesammte arbeit dieses Features (also max 1-2 monate) verlieren. Immernoch schlimm, aber "kaputt" geht da nix, man verliert höchsten kürzlich getätigte Arbeit.

Ich sollte an diesem punkt aber mal ein bisschen erläutern. Git ist nicht nur ein VCS sondern auch ein Dokumentations-tool. Als solches ist es wichtig die Commit historie sauber zu halten. Beispiel du hast ein neues feature entwickelt und auf deinem branch hast du die folgende commit historie:
  • Adding feature ... (* lange commit message mit vielen details *)
  • Fixing xyz
  • Fixing hij
  • fixing new bugs due to new hij functionality
  • adding tests for NEW Functionality
  • turns out xyz was never broken, restoring
  • fixing abc
  • fixing broken test
  • fixing broken test

Wenn jetzt jemand in die Historie sieht sieht er genau 2 relevante commits und 7 irrelevante, beim git blame würden auch ein großteil der Zeilen nur "fixing ..." sein. Das ist auf nem branch ok, auf dem master möchte man das dann aber nicht haben. Also setzt man sich hin und changed die historie, löscht die beiden xyz commits und squashed hij und abc fixes zusammen mit dem "Adding features" commit und die beiden "broken tests" zusammen mit dem "Adding tests ..." commit. Und am ende hat man 2 saubere commits, die dann auf master landen.

Das ist ein oftmals verwendeter workflow mit git der so mit SVN einfach nicht wirklich möglich. Wenn man aber auf eine saubere commit historie verzichtet, braucht man davor keine angst zu haben, da man dann komplett drauf verzichten kann.

Der andere punkt an dem man rebasen muss ist wenn 2 leute gleichzeitig an nem feature in einem branch arbeiten, Feature 1 wird gemerged, dann ist der Feature2 branch auf einem veralteten master. Was man dann normalerweise macht ist gegen master zu rebasen, dabei erkennt git den letzten gemeinsamen commit, und wendet dann alle neuen commits deines aktuellen branches auf den neuen master an. Du ersetzt also den alten master zu dem neuen master als deinen Basis/Historie, daher rebase.
Dabei wird jeder deiner commits die du seit dem alten master gemacht hast neu auf den neuen master applied, und damit kann in jedem einzelnen dieser commits ein konflikt entstehen. Wenn du beim beheben dieser konflikte nicht aufpasst, machst du aus perfectly working code einen haufen garbage. Im Gegensatz zu einem merge gegen master, bei dem alle konflikte in einem Merge-Commit aufgelöst werden, den du reverten kannst, hast du hier deine historie überschrieben und kannst so einfach nicht mehr zurück gehen. Das gesagt ist das problem eher geringer natur weil du nur code kaputt machen kannst der konflikte verursacht hat, also in den meisten fällen nur 2-3 stellen, du kannst also nicht deine ganze arbeit verlieren.

Mein kommentar damals war etwas überspitzt ausgedrückt, zwar stehe ich im Grund noch zu der Aussage das diese designentscheidungen in einem VCS nicht die besten sind, aber man ist eigentlich doch eher fern davon "alles kaputt" zu machen. Zum einen sollte man lokal ja immernoch ein bisschen testen, d.h. wenn alles kaputt wäre, dann würde man das lokal merken und nicht pushen, und eine funktionierende version wäre noch online. Zum anderen gewöhnt man sich ziemlich an, wenn man merkt das ein rebase sehr komplex wird den abzubrechen (kann man machen solang er noch ned durch ist, dann wird der originalstand wieder hergestellt) und erst mal einen backup branch zu erzeugen, auf den man im notfall zurückgreifen kann. Da branching keinen overhead kostet kann man das ganz einfach machen.

Und selbst wenn man alles verkackt hat, und den kaputten rebase gepusht hat, GitLab merkt sich jede Änderung nochmal separat von git wenn ein merge-request offen ist, und solang man sauber mit GitLab MR's arbeitet, kann man eigentlich keine infos verlieren.

Also während ich diese Design-Entscheidung immer noch nicht gut finde, macht sie nicht so viel kaputt.

Zugegeben ein Nachteil ist wenn 2 personen auf dem selben branch arbeiten, und einer rebased den branch und der andere pullt ganz normal, macht git einen merge der alle gerebaseten änderungen wiederherstellt und die Historie noch kaputter macht. Aber merges sind ganz einfach zu reverten, und eigentlich sollte man sich auch an die regel: 1 entwickler - 1 branch halten, sonst kommt man eh in teufels Küche

m.fuchs hat geschrieben:Und ein weiteres Zitat:
[...]
Das wiederum ist (für mich) eben gar kein Argument.

Das war im vergleich zu mercurial, die designtechnisch das ganze einfach besser gelöst haben. Im vergleich zu SVN bietet git einem doch deutlich mehr. Vor allem muss ich mittlerweile auch sagen habe ich den vollen funktionsumfang von GitLab kennen gelernt und auch wenn Git nicht das beste VCS sein mag, die tools die einem GitLab bietet machen eigentlich alle inconviniences von git weg

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von Socke »

m.fuchs hat geschrieben:Also die Aufgabenstellung ist klar. Ich leite die Entwicklungsabteilung und will auf einen Blick sehen können, wenn wer was gemacht hat. Sprich: Minion 1 fummelt an einer File A im Projekt Todesstern rum und committed. Dann brauche ich in kurzer Zeit eine Benachrichtigung dass er das gemacht hat. Ich kann mir dann nämlich überlegen, ob das irgendwelchen Impact hat, den ich mir mit ihm noch einmal ansehen muss.

Auf dem Zentralen Git-Repository kannst du per Git Hook ein Aktion nach dem Push durch einen Entwickler implementieren. Dieser Hook würde dann auf dem Server ausgeführt und könnte dort deine Benachrichtigung versenden - oder deinen Client über Updates informieren.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von FPK »

m.fuchs hat geschrieben:
Warf hat geschrieben:Ich werd nie verstehen wie man sich freiwillig SVN statt git antun kann, klar ist git zu anfangs komplizierter, aber hat halt auch deutlich bessere features,


Es hilft halt nur nichts, wenn es genau die Features nicht hat, die man eigentlich braucht: das seit mehr als 20 Jahren genutzte Entwicklungsmodell von FPC ist z. B. aufgrund des primitiven Cherrypick-Trackings von git nur schwer umsetzbar. Zwar besteht der Plan, nach 3.2.0 auf git umzusteigen, aber ganz glaube ich noch nicht daran, vor allem eben weil wir dann bzgl. der Verwaltung des Fixes-Branches wieder bei einer Funktionalität auf dem Niveau von CVS angelangt sind. Klar könnte man versuchen ein anderes Entwicklungsmodell umzusetzen, z. B. git-flow, aber das fehlt uns einfach die Manpower bzw. Leute, die Lust haben, sich mit dem Mergen und Testen auf zig Plattformen rumzuschlagen. Und wenn ich mir die Entwicklung der Softwarequalität in den letzten Jahren anschauen, dann bezweifle ich sowieso, ob die modernen Entwicklungsmodell wirklich das richtig sind.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von af0815 »

Wenn etwas genau auf die Stärken eines Systems abgestimmt ist, so kann es ohne Grundlegende Änderung am Workflow nur Verlierer geben.

Ich habe es relativ oft bei den Umstellungen von Abläufen von funktionierenden Systemen und Workflows auf SAP gesehen. (Ja ich habe es absichtlich so formuliert).
Wenn nicht zuerst der wirkliche Vorteil herausgearbeitet wird und nur umgestellt wird, so ist eine sehr schwierige Phase vorprogrammiert. (Optimistisch ausgedrückt).
Vor allen, wie bildet man liebgewonnene Workflows von SVN in GIT ab. Teilweise geht das gar nicht. Die einfache Aussage, ist ab Rev xxxx im Trunk gelöst, wie bildet man das im GIT ab !? Und das ist aber nur eine absolute Kleinigkeit.
Meiner Meinung nach geht das nur durch einen Diktator :shock: So wie, meiner Meinung nach, im Kernel passiert ist. Bzw. wenn es eine große wichtige Gruppe für absolut wichtig hält. Nur ist immer die Frage ob die Manpower nicht besser im Projekt als der Projektverwaltung steckt.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von Socke »

af0815 hat geschrieben:Ich habe es relativ oft bei den Umstellungen von Abläufen von funktionierenden Systemen und Workflows auf SAP gesehen. (Ja ich habe es absichtlich so formuliert).

SAP kann ab dem aktuellen Release auch GIT. Aber nur Teilweise. Bisher habe ich damit noch nicht gearbeitet und bin gespannt, wie der Hersteller das umgesetzt hat. Wird man dann beim nächsten Releasewechsel einfach ein 40 Gigabyte Repository auschecken?
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: GIT-Workflow vs. SVN-Workflow

Beitrag von af0815 »

Socke hat geschrieben:
af0815 hat geschrieben:Ich habe es relativ oft bei den Umstellungen von Abläufen von funktionierenden Systemen und Workflows auf SAP gesehen. (Ja ich habe es absichtlich so formuliert).

SAP kann ab dem aktuellen Release auch GIT. Aber nur Teilweise. Bisher habe ich damit noch nicht gearbeitet und bin gespannt, wie der Hersteller das umgesetzt hat. Wird man dann beim nächsten Releasewechsel einfach ein 40 Gigabyte Repository auschecken?

Die Aussage von mir hat sich auf Abläufe und Workflows bezogen. Nicht auf die integration von GIT.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: Suche Möglichkeiten, um ein Programm zu veröffentlichen

Beitrag von marcov »

Warf hat geschrieben:
Mit SVN kann man also damit rechnen das man etwa einen faktor 60-100 mehr an Zeit aufwenden muss einfach nur weil es so viel länger braucht für alles


Sind das auch mit gleiche Protokolle ? SVN tut svn, svn+ssh + http + https. Auch kann SVN teilen von repos überholen.

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1430
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: Suche Möglichkeiten, um ein Programm zu veröffentlichen

Beitrag von fliegermichl »

marcov hat geschrieben:
Warf hat geschrieben:
Mit SVN kann man also damit rechnen das man etwa einen faktor 60-100 mehr an Zeit aufwenden muss einfach nur weil es so viel länger braucht für alles


Sind das auch mit gleiche Protokolle ? SVN tut svn, svn+ssh + http + https. Auch kann SVN teilen von repos überholen.


Ja, ich nutze GIT mit dem ssh Protokoll. github verwendet https. Man kann mit git submodule erzeugen. Das sind separate Repositories die mit dem Hauptrepository synchronisieren.
Standardmäßig wird aber nur das Mainrepository geklont.

Antworten