Git zentralisiert vs dezentralisiert
-
computertrolls schrieb:
Bei Subversion müsste man mit branches arbeiten -> unflexibel.
Natürlich würde man bei Subversion mit Branches arbeiten, genau dafür sind die da. Und warum das unflexibel sein soll, das müsstest du erst noch erklären.
-
Ich sag nur: Mercurial
-
Printe schrieb:
computertrolls schrieb:
Bei Subversion müsste man mit branches arbeiten -> unflexibel.
Natürlich würde man bei Subversion mit Branches arbeiten, genau dafür sind die da. Und warum das unflexibel sein soll, das müsstest du erst noch erklären.
Ich würde nicht sagen, dass Branches unflexibel sind, aber mir gefällt nicht wie sie in SVN implementiert sind. Es sind praktisch nur Ordner, die mit den mergeinfo properties eine Beziehung zu anderen Ordner haben.
Deswegen gibt es keinen SVN Befehl um zu einem Branch zu wechseln oder zu mergen. Das geht alles über URLs. Ich hab mir deswegen einen Wrapper erstellt der die URL aus dem Branchnamen generiert. Das funktioniert aber nur solange die Branches die gleiche Struktur wie der trunk haben. Da man im SVN auch einzelne Order (wir haben mehrere Projekte pro Repo) aus dem trunk branchen und mergen kann, sparen sich viele Entwickler die kompletten Branches. So lässt sich die URL nicht mehr einfach nur aus dem Branchnamen herleiten. Da bleibt nichts anderes als sich die URL zu browsen, was sich über den Server eher langsam anfühlt.
Die mergeinfo properties sind auch wie Code anfällig für Mergekonflikte. Wir haben da ein paar Branches rumliegen, bei denen keiner mehr weiß welchen Stand die haben, weil die mergeinfos nicht mehr stimmen. Die müsste man manuell aus der History rekonstruieren. Die Konflikte vermeiden geht leider nicht zuverlässig, wenn man mehrere Versionen pflegen muss und deswegen zwischen Branches von Branches merged.
-
Schonmal Branch-Creation-Time und Branch-Switch-Time zwischen Subversion und Git verglichen? Branches in Subversion sind imho sehr schwerfällig und nicht für kleine Änderungen sondern nur größere Stories gedacht.
MfG SideWinder
-
Dank git-svn ist es mir fast egal ob svn- oder git-server.
Aber bei den SVN-Workflows, die ich kennengelernt habe, wurden immer mehrere Bugs in einem SVN-Commit gesammelt. mit schlechten Diffs.
Ist das bei euch anders? Ein SVN-Commit pro Bugfix? Mit SVN-Client ohne lokale commits macht das ja keinen Spaß.
-
man git reset schrieb:
Ist das bei euch anders? Ein SVN-Commit pro Bugfix?
Ja. Hab ich doch geschrieben, immer wenn ich einen Schritt fertig habe (einen Bugfix, ein Feature), wird der committet.
Das war nicht immer so, und ich gebe zu, dass meine Erfahrungen mit git einen gewissen Einfluss darauf hatten. Aber es erweist sich immer wieder als praktisch.
Mit SVN-Client ohne lokale commits macht das ja keinen Spaß.
Mit "lokale commits" meinst du einen SVN-Server im LAN? Den haben wir natürlich, oder denkst du, wir speichern unser Software-Knowhow in einer Cloud, außerhalb unserer Kontrolle?
-
Nein, ich meine das git-Repo lokal am eigenen Arbeitsplatz. Ohne dem, wenn du immer direkt jede Änderung zum Server pushst, hast du doch bestimmt eine hohe "fixup-Commit"-Quote und die einzelnen Commits haben selten noch den ganzen Stand.
Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?
-
man git reset schrieb:
Ohne dem, wenn du immer direkt jede Änderung zum Server pushst, hast du doch bestimmt eine hohe "fixup-Commit"-Quote und die einzelnen Commits haben selten noch den ganzen Stand.
? Verstehe ich nicht. Was meinst du mit "fixup-commit" und "selten den ganzen Stand"?
Wenn ich was fertig habe, mache ich svn commit -m "kommentar". Vorher prüfe ich mit svn status und svn diff, ob alles Nötige drin ist im Commit (und alles Unnötige draußen).
Machst du das etwa nicht? Committest du mit der heißen Nadel? Brauchst du mehrere Anläufe, bis du endlich alles im Kasten hast? Dann ist nicht git die Lösung, sondern mehr Sorgfalt beim Arbeiten.
Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?
Dass ein Kollege hier reinstürzt und SOFORT dies und das von mir haben will und auf KEINEN Fall warten kann, das passiert nicht. Der muss mir sagen "ich brauch das in ein paar Tagen", dann mache ich das rechtzeitig. Umgekehrt natürlich genauso, auch ich muss früh genug Bescheid sagen, wenn andere was für mich tun sollen.
Und wenn doch was hart dazwischenfliegt, dann kann das nur ein Hotfix sein, der auf einer bereits releasten Version gemacht werden muss. Das heißt, ich muss mir dafür eh den zugehörigen Release-Branch holen, und der ist natürlich sauber.
Was willst du hier eigentlich beweisen? Dass Subversion kacke ist, dass jeder, der noch damit arbeitet, wohl hinterm Mond lebt? Ich weiß sehr wohl, dass git Vorzüge hat, und würden wir heute nochmal ein VCS einführen, dann würde wir uns wohl für git entscheiden. Aber die Entscheidung ist vor mehr als 10 Jahren gefallen, und wir verwalten sehr viel mit Subversion, bei weitem nicht nur Software-Quellcode. Das alles umzustellen und zu migrieren würde Monate verschlingen, und dafür tut Subversion einfach noch nicht genug weh.
-
Printe schrieb:
Das alles umzustellen und zu migrieren würde Monate verschlingen, und dafür tut Subversion einfach noch nicht genug weh.
Das kann ich mir nicht vorstellen.
Ich würde sogar vermuten, dass es Tools gibt, mit dem man den Umstieg automatisieren kann, sogar inklusive der Versionshistorie.
Open Source Projekte kriegen es ja auch hin und die haben viel weniger Zeit.
-
man git reset schrieb:
Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?
Per svn diff einen Patch erzeugen, Änderungen reverten und hinterher Patch wieder einstellen.
computertrolls schrieb:
Ich würde sogar vermuten, dass es Tools gibt, mit dem man den Umstieg automatisieren kann, sogar inklusive der Versionshistorie.
Das Repo selber ist nicht das Problem. Aber danach muss man sämtliche Build-Jobs und andere Skripte, die auf SVN basieren, umstellen.
-
Printe schrieb:
Was willst du hier eigentlich beweisen?
Gar nichts
Ich habe darauf hingewiesen, dass man git auch als SVN-Client benutzen kann.Dann muss in der Firma nichts umgestellt werden und man hat trotzdem viele Vorteile von git (eben das Patch-Management was Tobiking2 manuell macht und Du scheinbar nicht nötig hast).
-
Printe schrieb:
Ein Wechsel der Infrastruktur bedeutet immer Aufwand:
- Jemand muss sich tief in Git einarbeiten, so tief, dass er ein Repo administrieren und das alte Subversion-Repo zu Git migrieren kann.
- Das ganze Team muss sich weit genug in Git einarbeiten, um sicher damit umgehen zu können.
- Es müssen Regeln aufgestellt, vermittelt und allgemein akzeptiert werden, wie mit zentralen und verteilten Repos umzugehen ist.
- Arbeitsumgebungen (IDEs, automatische Build- und Testsysteme, ...) müssen umgestellt und getestet werden.
- Evtl. muss neue Server-Hardware angeschafft werden, was auch wieder Aufwand (Installation, Pflege, Updates, Backups) bedeutet.
Das ist nicht wenig, und solange niemandem ernsthaft was an Subversion fehlt, ist es keine dumme Idee, dabei zu bleiben.
Es ist eine der dümmsten Ideen aller Zeiten. Ich kann parallell Git und SVN auf eine Kiste als Zentralinstanz packen und den Übergang administrativ leiten. Selten so was smoothes erlebt. Mit Tortoise Tools gehts ganz locker, meinetwegen mit Doppeleinpflege.
Aber mach mal nen Server temporär tot, da geht mit SVN nix weida. Bei Git können alle weiterwursteln, bis zentral wieder was geht. Unschätzbare Vorteile. Jeder kann weiter forken und seinen Testkram weiter sichern, bis er seinen Teil weitergibt. Kann SVN ohne Zentralinstanz einfach nicht.
