it-swarm.com.de

Was macht SVN besser als Git?

Keine Frage, dass die Mehrheit der Debatten über Programmierwerkzeuge entweder auf persönliche Wahl (vom Benutzer) oder Designschwerpunkte abzielt , , dh , Optimierung des Designs gemäß bestimmten Anwendungsfällen (vom Tool Builder). Texteditoren sind wahrscheinlich das bekannteste Beispiel - ein Codierer, der unter Windows bei der Arbeit arbeitet und in Haskell auf dem Mac zu Hause codiert, plattformübergreifende und Compiler-Integration schätzt und sich daher für Emacs) entscheidet over TextMate usw.

Es ist weniger üblich, dass eine neu eingeführte Technologie den vorhandenen Optionen nachweislich überlegen ist.

Ist dies tatsächlich bei Versionskontrollsystemen (VCS) der Fall, insbesondere bei zentralisierten VCS ( [~ # ~] cvs [) ~ # ~] und SVN ) versus verteiltes VCS (- Git und Mercurial )?

Ich habe SVN ungefähr fünf Jahre lang verwendet, und SVN wird derzeit dort verwendet, wo ich arbeite. Vor etwas weniger als drei Jahren wechselte ich für alle meine persönlichen Projekte zu Git (und GitHub).

Ich kann mir eine Reihe von Vorteilen von Git gegenüber Subversion vorstellen (und die größtenteils abstrakt zu den Vorteilen von verteiltem über zentralisiertem VCS sind), aber ich kann mir kein Gegenbeispiel vorstellen - eine Aufgabe (die relevant ist und bei einem Programmierer üblich ist Workflow), dass Subversion besser macht als Git.

Die einzige einzige Schlussfolgerung, die ich daraus gezogen habe, ist, dass ich keine Daten habe - nicht, dass Git besser ist usw.

Ich vermute, dass solche Gegenbeispiele existieren, daher diese Frage.

294
doug

Subversion ist ein zentrales Repository

Während viele Benutzer verteilte Repositorys für die offensichtlichen Vorteile von Geschwindigkeit und mehreren Kopien haben möchten, gibt es Situationen, in denen ein zentrales Repository wünschenswerter ist. Wenn Sie beispielsweise einen kritischen Code haben, auf den niemand zugreifen soll, möchten Sie ihn wahrscheinlich nicht unter Git stellen. Viele Unternehmen möchten ihren Code zentralisieren, und (ich denke) alle (ernsthaften) Regierungsprojekte befinden sich in zentralen Repositories.

Subversion ist konventionelle Weisheit

Dies bedeutet, dass viele Leute (insbesondere Manager und Chefs) die übliche Methode haben, die Versionen zu nummerieren und die Entwicklung als "einzelne Linie" zu betrachten, die im Laufe der Zeit fest in ihrem Gehirn codiert ist. Nichts für ungut, aber Gits Liberalität ist nicht leicht zu schlucken. Das erste Kapitel eines Git-Buches sagt Ihnen, dass Sie alle herkömmlichen Ideale aus Ihrem Kopf streichen und neu beginnen sollen.

Subversion macht es in eine Richtung und nichts anderes

SVN ist ein Versionskontrollsystem. Es hat eine Möglichkeit, seine Arbeit zu erledigen, und jeder macht es auf die gleiche Weise. Zeitraum. Dies erleichtert den Übergang zu/von SVN von/zu anderen zentralisierten VCS. Git ist NICHT einmal ein reines VCS - es ist ein Dateisystem, hat viele Topologien zum Einrichten von Repositorys in verschiedenen Situationen - und es gibt keinen Standard. Das macht es schwieriger, eine zu wählen.

Weitere Vorteile sind:

  • SVN unterstützt leere Verzeichnisse
  • SVN bietet eine bessere Windows-Unterstützung
  • SVN kann einen Unterbaum auschecken/klonen
  • SVN unterstützt die exklusive Zugriffskontrolle svn lock, Die für schwer zusammenführbare Dateien nützlich ist
  • SVN unterstützt Binärdateien und große Dateien einfacher (und erfordert nicht das Kopieren alter Versionen überall).
  • Das Hinzufügen eines Commits erfordert erheblich weniger Schritte, da kein Pull/Push erfolgt und Ihre lokalen Änderungen immer implizit auf svn update Zurückgesetzt werden.
206
treecoder

Ein Vorteil von Subversion gegenüber Git can ist, dass Subversion nur das Auschecken von Unterbäumen ermöglicht. Mit Git ist das gesamte Repository eine Einheit, Sie können nur alles oder nichts bekommen. Mit modularem Code kann dies im Vergleich zu Git-Submodulen recht gut sein. (Während Git-Submodule natürlich auch ihren Platz haben.)

Und ein kleiner kleiner Vorteil: Subversion kann leere Verzeichnisse verfolgen. Git verfolgt den Dateiinhalt, sodass ein Verzeichnis ohne Datei nicht angezeigt wird.

131
johannes

Ich kann mir drei vorstellen. Erstens ist es ein bisschen einfacher zu groken, besonders für Nicht-Entwickler. Konzeptionell ist es viel einfacher als DCVS Optionen. Zweitens ist die Reife, insbesondere TortoiseSVN unter Windows. TortoiseHg holt allerdings schnell auf. Drittens kann die Natur des Tieres - nur ein Bild eines Dateisystems, in dem Sie Dinge von jeder Ebene des Baums aus überprüfen können - in einigen Szenarien sehr nützlich sein - beispielsweise bei der Versionierung einer Vielzahl sehr unterschiedlicher Konfigurationsdateien über Dutzende von Servern ohne Dutzende von Repositorys.

Das heißt nicht, dass wir nicht die gesamte Entwicklung auf Mercurial umstellen.

51
Wyatt Barnett
  • SVN-Repositorys sind aus Sicht eines Managers und Administrators besser zu verwalten ( ACL + Authentifizierungsmethoden + Hotcopy + Spiegel + Dumps)
  • SVN * -Hooks sind einfacher zu implementieren und zu unterstützen
  • svn:external hat mehr Leistung und Flexibilität als Submodule
  • Dateisystembasierte Repository-Bäume sind einfacher zu verwenden als monolithische Repositorys mit nur logischer Trennung
  • SVN hat mehr verschiedene Client-Tools
  • SVN verfügt über nutzbare Web-Frontends von Drittanbietern, die viel besser sind als die von Git
  • SVN bricht Ihr Gehirn nicht
32
Lazy Badger

Ich habe dies als Kommentar zur Antwort eines anderen geschrieben, aber ich denke, es verdient eine Antwort an und für sich.

Die sorgfältig ausgewählte Konfiguration meines Unternehmens für SVN erfordert eine Sperre auf Dateiebene, um Inhalte zu bearbeiten, und verwendet niemals die Zusammenführung. Infolgedessen kämpfen mehrere Entwickler um Sperren, und dies kann ein schwerwiegender Engpass sein, und es besteht nie die Möglichkeit eines Zusammenführungskonflikts.

SVN macht definitiv eine Top-Down-Managementkontrolle besser als Git. Bei meiner Skunkworks-Migration zu Git (um Vergebung anstatt um Erlaubnis zu bitten) habe ich meinen Manager oft mit der Vorstellung erschreckt, dass es keine Software gibt -erzwungener zentraler Master-Steuerungsserver, für den wir alle Slaves sind.

24
Dan Ray

Ich weiß es zu schätzen, dass Sie nach guten Informationen suchen, aber diese Art von Frage lädt nur ein: "Ich denke, Git ist so viel Gewinn und svn teh suxorz!" Antworten.

Ich habe versucht, Git persönlich etwas zu viel für mein kleines Team zu finden. Es schien großartig für ein großes verteiltes Team oder eine Gruppe von Teams zu sein, die geografisch verteilt sind. Ich verstehe die Vorteile von Git sehr gut, aber die Quellcodeverwaltung hält mich meiner Meinung nach nachts nicht auf.

Ich bin ein Hirschjäger, und wenn ich und meine Freunde ausgehen, sind sie bis an die Zähne bewaffnet, voller Munition und High-Tech-Ausrüstung. Ich tauche mit einem einzigen Gewehr, sieben Kugeln und einem Bockmesser auf. Wenn ich mehr als sieben Runden brauche, mache ich etwas falsch und ich mache es genauso gut wie alle anderen.

Der Punkt, den ich versuche, ist, dass wenn Sie ein kleines Team sind, das an einem mittleren bis kleinen Projekt arbeitet und Sie bereits mit SVN vertraut sind, Sie es verwenden. Es ist sicherlich besser als CVS oder (shudder) SourceSafe , und ich brauche nicht mehr als fünf Minuten, um ein Repository einzurichten. Git kann manchmal übertrieben sein.

23
maple_shaft

Meine Gründe:

  • reife - sowohl der Server als auch die Tools (z. B. TortoiseSVN)
  • einfachheit - ohne Schritte ist ein Commit ein Commit. DVCS wie Git und Mercurial beinhalten Commit und dann Push.
  • binärbehandlung - SVN verarbeitet binäre ausführbare Dateien und Bilder besser als Git/Hg. Besonders nützlich bei .NET-Projekten, da ich Build-bezogene Tools in der Quellcodeverwaltung überprüfen möchte.
  • nummerierung - SVN verfügt über ein lesbares Commit-Nummerierungsschema, bei dem nur Ziffern verwendet werden. Dies erleichtert die Verfolgung von Revisionsnummern. Git und Hg machen das ganz anders.
22
Grant Palin

Dies ist alles relativ und wie maple_shaft sagte, wenn man für Sie arbeitet, nicht ändern!

Aber wenn Sie wirklich etwas wollen , würde ich sagen, dass es vielleicht besser für Designer, Webprogrammierer und dergleichen ist - es handhabt Bilder und Binärdateien) Dateien etwas besser.

20
Rook

Benutzerfreundlichkeit. Es ist nicht wirklich Subversions Verdienst, sondern TortoiseSVN 's .. TortoiseGit existiert, aber es ist noch ein langer Weg, um TortoiseSVN zu entsprechen.

Wenn Sie fragen würden, was Git besser macht als SVN, würde ich antworten GitHub . Es ist lustig, wie große Tools von Drittanbietern einen so großen Unterschied machen.

18
Thomas Bonini

Wenn Sie nicht verzweigen und zusammenführen müssen , ist SVN (mit TortoiseSVN unter Windows) sehr einfach zu verstehen und zu verwenden . Git ist für die einfachen Fälle zu komplex, da es versucht, das Verzweigen/Zusammenführen zu vereinfachen.

(Viele kleine Projekte müssen nie verzweigen, wenn sie gut verwaltet werden. Git ist auf die komplexen Fälle ausgerichtet. Daher wird in den meisten Git-Dokumentationen davon ausgegangen, dass Sie komplexe Vorgänge wie Verzweigen und Zusammenführen ausführen müssen.)

16
Ian

Nun, mein Opa könnte SVN auf seinem Windows XP-Computer verwenden, aber er hätte Probleme mit Git. Vielleicht ist dies eher eine Leistung von TortoiseSVN over TortoiseGit , aber ich denke, es hängt eher damit zusammen, dass Git von Natur aus leistungsfähiger und damit komplexer ist und es auch sein würde Es ist sinnlos, es auf das gleiche Niveau zu bringen.

Jetzt ist es für meinen Opa nicht wirklich wichtig, weil er in letzter Zeit keine Programmierung mehr gemacht hat. Ich war jedoch einmal in einem Team, in dem unsere Grafiker auch unsere Quellcodeverwaltung verwendeten.

Und das sind Leute, die einfach erwarten, dass ihre Werkzeuge funktionieren (ich auch, aber ich habe eine realistische Chance, sie im Fehlerfall zum Arbeiten zu bringen) und intuitiv sind. Abgesehen von der Tatsache, dass es eine ziemliche Anstrengung gewesen wäre, sie dazu zu bringen, mit einem DVCS auszukommen, gab es wenig zu gewinnen. Und mit nur zwei Programmierern im Team war es für uns sinnvoll, auch nur bei SVN zu bleiben.

14
back2dos

Bei der Arbeit konnte ich die Entwickler aus zwei Gründen nicht von SVN auf DVCS umstellen:

  • Teilkassen (wie nur drei Ordner aus verschiedenen Tiefen im Projektbaum)
  • Dateisperrung (Berichte im Binärformat)
11
alexandrul
  • Sicherheitsgefühl bei einem 'svn commit'. Da Commits an den Server gehen, gibt es keine Möglichkeit, dass ich meine Änderungen lösche, nachdem sie festgeschrieben wurden. In git sind Commits lokal, also bis ich Push, ein streunendes 'rm -rf' und alles vorbei ist.
  • Commits werden authentifiziert. Standardmäßig in Git kann ich sagen, dass ich mich wie jeder andere verpflichte.
  • Weniger Befehle für den täglichen Gebrauch. 'svn checkout', 'svn up' und 'svn commit' bringen Sie ziemlich weit.
  • Geteilte Kassen funktionieren viel besser. Wenn Sie zum Festschreiben gehen, werden Sie nach Ihrem Benutzernamen/Kennwort gefragt. Sie müssen nicht daran denken, bestimmte Befehlszeilenargumente zu übergeben. Manchmal haben wir bei der Arbeit einen gemeinsam genutzten Computer mit einem gemeinsam genutzten SVN-Checkout für ein Projekt. Jemand könnte sagen "Bob, können Sie sich das auf diesem Computer ansehen?" Und er kann, und er kann seine Änderungen als Benutzer ohne Fehler übernehmen.
  • Repository-Layout. Sie können ein Dachprojekt und Teilprojekte haben und auswählen, was wann ausgecheckt werden soll.
  • Revisionsnummern erhöhen ganze Zahlen.
  • Entwickelt für den zentralen Repository-Workflow.
8
Tim

Andere Leute haben einige ziemlich gute Antworten gepostet, aber was ist mit Berechtigungen? Mit Subversion über SSH können Sie auf Ihrem Server ein separates Konto für SVN erstellen. Verschiedene Entwickler können unterschiedlichen Zugriff auf verschiedene Teile des Repositorys erhalten. Kann GIT das tun? Ich denke, es gibt Capitolit, aber es scheint mir einfach nicht so flexibel oder robust zu sein, und ich kenne auch niemanden, der es tatsächlich verwendet.

6
GlenPeterson

Geschwindigkeit. Manchmal dauert das Klonen eines großen Git-Repositorys 10 oder 15 Minuten, während das Auschecken eines Subversion-Repositorys ähnlicher Größe einige Minuten dauert.

5
calum_b

Subversion und Git fördern beide bestimmte (und sehr unterschiedliche) Ansätze für Entwicklung und Zusammenarbeit. Einige Organisationen werden je nach Organisation und Kultur mehr aus Git herausholen, andere mehr aus Subversion.

Git und Mercurial eignen sich hervorragend für verteilte und locker organisierte Teams hochkompetenter professioneller Programmierer. Diese beiden beliebten DVCS-Tools fördern kleine Repositorys, wobei die Wiederverwendung zwischen Entwicklern über veröffentlichte Bibliotheken mit (relativ) stabilen Schnittstellen erfolgt.

Subversion hingegen fördert eine zentralere und eng gekoppelte Managementstruktur mit mehr Kommunikation zwischen Entwicklern und einem höheren Maß an organisatorischer Kontrolle über die täglichen Entwicklungsaktivitäten. Innerhalb dieser kompakter organisierten Teams erfolgt die Wiederverwendung zwischen Entwicklern in der Regel über unveröffentlichte Bibliotheken mit (relativ) instabilen Schnittstellen. TortoiseSVN ermöglicht Subversion auch die Unterstützung multidisziplinärer Teams mit Mitgliedern, die keine professionellen Programmierer sind (z. B. Systemingenieure, Algorithmusingenieure oder andere Fachspezialisten).

Wenn Ihr Team verteilt ist und Mitglieder entweder von zu Hause oder von vielen verschiedenen internationalen Standorten aus arbeiten oder wenn sie es vorziehen, alleine und in Stille mit wenig persönlicher Kommunikation zu arbeiten, ist ein DVCS wie Git oder Mercurial eine gute Wahl kulturelle Passform.

Wenn sich Ihr Team andererseits an einem einzigen Standort befindet, mit einem aktiven "Team" -Ansatz für die Entwicklung und viel persönlicher Kommunikation mit einem "Summen" in der Luft, kann SVN ein Bessere kulturelle Passform, insbesondere wenn Sie viele interdisziplinäre Teams haben.

Natürlich ist es möglich, Git und Hg (so leistungsfähig und flexibel sie auch sind) so zu konfigurieren, dass sie so ziemlich alles tun, was Sie wollen, aber es ist definitiv mehr Arbeit und sie sind definitiv schwieriger zu verwenden, insbesondere für diejenigen Mitglieder des Teams, die würde natürlich nicht geneigt sein, irgendeine Form der Versionskontrolle zu verwenden.

Schließlich finde ich auch, dass die gemeinsame Nutzung von Funktionen mithilfe der "heißen" Bibliotheksentwicklung unter Svn (mit CI und einem testgetriebenen Ansatz) ein Tempo der koordinierten Entwicklung ermöglicht, das mit einem verteilten und locker gekoppelten Team nur schwer zu erreichen ist.

4
William Payne

Ich poste dies eher als Antwort als als Kommentar.

Ich gebe zu, dass DVCS momentan ziemlich im Trend sind, aber ich werde versuchen zu erklären, warum.

DVCS sind besser, weil genau wie viele Leute gesagt haben: "So hätten wir von Anfang an arbeiten sollen." Es ist wahr, Sie können mit einem DVCS das tun, was Sie früher mit SVN getan haben, also auf eine Weise, die SVN überflüssig macht.

Allerdings ist nicht jedes Softwareprojekt so gut wie es nur geht:

  • Langzeitprojekte haben viel von DVCS profitiert, da es weniger Overhead benötigt, eine viel bessere Verwaltung (Verzweigung usw.) ermöglicht und von Hosts wie Google Code und Github stark unterstützt wird.

  • Diese Projekte sind nicht die einzigen, es gibt andere Arten von Projekten, die in Unternehmen ohne Unterstützung durch die Außenwelt oder das Internet entwickelt werden: Alles wird intern und oft kurzfristig durchgeführt. Ein gutes Beispiel: ein Videospiel. Code entwickelt sich schnell.

Für den letzteren Fall benötigen Entwickler keine Verzweigung oder ausgefeilten Funktionen, die DVCS bieten kann. Sie möchten lediglich Quellcode und Assets gemeinsam nutzen. Der von ihnen erstellte Code wird wahrscheinlich nicht wiederverwendet, da es eine Frist gibt. Sie verlassen sich aus mehreren Gründen eher auf SVN als auf ein DVCS:

  • Entwickler haben Maschinen, die zum Unternehmen gehören, und dies kann sich schnell ändern. Das Konfigurieren eines Repos ist ein Zeitverlust.
  • Wenn diese Leute keine eigene Maschine haben, ist es weniger wahrscheinlich, dass sie an demselben Quellcode/Teil des Projekts arbeiten. Plus eins für die zentralisierten Daten.
  • netzwerkgeschwindigkeiten und viel Geld ermöglichen die Verwendung eines zentralen Servers, der sich um alles SVN kümmert. Es ist eine schlechte Praxis, aber Backups werden erstellt usw.
  • SVN ist einfach einfacher zu verwenden, auch wenn es der falsche Weg ist: Das Synchronisieren von Dateien auf Peers ohne Redundanz ist kein einfaches Problem, und "es richtig machen" kann es einfach nicht rechtzeitig schaffen, wenn Sie es immer tun möchte, dass es perfekt ist.

Denken Sie an die Spieleindustrie und wie SVN Zeit spart. Die Leute kommunizieren viel mehr über diese Projekte, weil es bei Spielen um sich wiederholende Programmierung und adaptiven Code geht: Es ist nicht schwer zu codieren, aber es muss so schnell wie möglich richtig gemacht werden. Programmierer werden eingestellt, sie codieren ihren Teil, kompilieren ihn, testen ihn ein wenig, verpflichten sich, erledigen, Spieletester kümmern sich um den Rest.

DVCS sind für das Internet und für sehr komplexe Projekte gemacht. SVN sind für kleine, kurzfristige, enge Teamprojekte gedacht. Sie müssen nicht viel von SVN lernen, es ist fast ein FTP mit einem dummen Unterschied.

4
jokoon

Nachfolgend sind die beiden Gründe aufgeführt, warum ich immer noch bei SVN bleibe.

  1. Die Lernkurve. SVN ist einfacher als Git, sogar das Setup (Server oder Client auch), die Benutzerfreundlichkeit und die Befehle.
  2. Bessere Serverpakete wie Subversion Edge , VisualSVN , berSVN usw.
2
Cheung

Derzeit gibt es zwei Haupttrends bei der Versionskontrolle. Verteilung und Integration .

Git ist großartig in der Dezentralisierung.

SVN verfügt über viele integrierte Tools. Es ist üblich, Ihren SVN-Server so einzurichten, dass Sie beim Einchecken eines Fixes die Fehlernummer im Check-in-Kommentar erwähnen. Diese wird automatisch auf den Status "In Test" gesetzt und der zugewiesene Tester benachrichtigt, den er benötigt schau es dir an. Anschließend können Sie eine Version markieren und eine Liste aller in dieser Version behobenen Fehler abrufen.

Die Tools, die dies mit SVN tun, sind ausgereift und werden jeden Tag verwendet.

1
Sean McMillan