nicht angemeldet
Tach!
"Mit git wäre das nicht passiert"
Das hab ich mir auch für'n paar Sekunden gedacht. Trotzdem bleibe ich bei SVN, das eigentliche Problem war wieder einmal ein Hardware-RAID-Controller.
Ja, stimmt schon, aber nachdem ich mir Git angesehen und erste Erfahrungen damit gemacht hatte, kann ich ein Bleiben bei SVN nur noch mit Konservativismus begründen (oder mit dem Bauern, der etwas nicht isst, nur weil er es nicht kennt). Sei es drum. Ich will dich jetzt nicht (unbedingt) überzeugen, aber ein paar mehr Worte, warum Git hier im Vorteil gewesen wäre, werde ich doch noch verlieren.
Bei SVN ist man auf Gedeih und Verderb auf das zentrale Repository angewiesen. Ist es nicht erreichbar, kann man nichts weiter machen, als in seinem derzeitigen Stand Änderungen vorzunehmen. Man kann dazu weder einen neuen Branch eröffnen, um die Entwicklung der Hauptlinie nicht zu beeinflussen, noch kann man aus seinen Zwischenschritten in ein Commit erstellen. Wenn das zentrale Repo dann wieder verfügbar ist, kann man nur einen "Monster"-Commit hinlegen oder man hätte während seiner Arbeit für die Zwischenstände Patches erstellen müssen, die man dann nachträglich Schritt für Schritt anwendet und dabei die Versionen einzeln eincheckt.
Die dezentrale Struktur von Git ist hier deutlich im Vorteil. Man kann alles lokal machen und dann in einem Zug das zentrale Repo updaten. Und "das zentrale Repo" ist auch nicht richtig ausgedrückt, denn man kann beliebig viele Remote-Repositorys anbinden. Wenn ein Remote-Repo ausfällt, kann man es recht einfach wieder aus jedem aktuellen lokalen Clone wiederherstellen. Aus veralteten Backups erstellte Repos stellen ebenfalls keine Hürde dar. Das Delta kann man ebenfalls aus einem lokalen Clone ausgleichen.
Neulich hatte ich das Bedürfnis, ein fremdes Projekt in meiner eigenen Anwendung zu verwenden, aber nicht genauso, wie es der Autor erschaffen hatte, sondern ein paar Änderungen einzubauen. Diese waren nicht für die Öffentlichkeit nützlich/vorgesehen. Aber ich wollte auch Änderungen des Projekts übernehmen können. Das heißt, ich konnte nicht einfach nur eine Kopie erstellen und mit der arbeiten. Dann hätte ich alle Änderungen händisch rübertransportieren müssen. Eine Anbindung an das Projekt und die Möglichekkeit, eigene Änderungen zu pflegen, wäre also sehr hilfreich. Dummerweise war das Projekt ein mit SVN gepflegtes Projekt und SVN half mir bei meinem Vorhaben nicht. Um einen Branch zu erstellen, hätte ich im zentralen Repository schreiben können müssen. Der wäre dann aber auch nicht mehr rein privat gewesen. Mit Git wäre das kein Problem. Man klone das zentrale Projekt, und branche und commite dann privat nach Herzenslust. Gelegentlich fetche man die zentralen Änderungen in den Hauptzweig und merge sie in den privaten. Gitseidank (scnr) war das konkrete Problem ebenfalls einfach zu lösen. Git kann auch SVN-Projekte clonen. Dann kann man privat arbeiten und gelegentlich mal fetchen und mergen. Und das heißt auch, dass man problemlos von SVN auf Git umsteigen kann: einfach einbinden.
Von SVN kommend ist die Einarbeitungszeit gering. Clone (Checkout), Fetch/Pull (Update) und Commit kennt man, geht nicht viel anders. Branchen und Mergen muss man vielleicht erst ein paar mal üben, weil man das bei SVN nicht so häufig macht. Aber bei Git geht das so einfach und schmerzlos, dass man das viel öfter einsetzen kann. Selbst wenn man sich vertan hat oder das neue Feature nur ein ganz kleines ist: kein Problem, Branch löschen geht ebenso einfach. Als 08/15-Anwender hab ich noch nichts gefunden, wo Git mir Nachteile gebracht hätte. Ein Umsteigen lohnt sich in der Regel. Zumindest schadet es nicht auf den ersten Blick. Der Geschmack kommt dann beim Essen.
dedlfix.