Ich benutze Subversion seit ein paar Jahren und nachdem ich SourceSafe verwendet habe , liebe ich Subversion einfach. In Kombination mit TortoiseSVN kann ich mir nicht vorstellen, wie es besser sein könnte.
Es gibt jedoch eine wachsende Anzahl von Entwicklern, die behaupten, dass Subversion Probleme hat und dass wir auf die neue Generation verteilter Versionskontrollsysteme wie Git umsteigen sollten .
Wie verbessert Git Subversion?
Antworten:
Git ist nicht besser als Subversion. Ist aber auch nicht schlimmer. Es ist anders.
Der Hauptunterschied besteht darin, dass es dezentralisiert ist. Stellen Sie sich vor, Sie sind ein Entwickler unterwegs, entwickeln auf Ihrem Laptop und möchten eine Quellcodeverwaltung, damit Sie 3 Stunden zurückgehen können.
Mit Subversion haben Sie ein Problem: Das SVN-Repository befindet sich möglicherweise an einem Ort, den Sie nicht erreichen können (in Ihrem Unternehmen, und Sie haben derzeit kein Internet). Sie können keine Festschreibung vornehmen. Wenn Sie eine Kopie Ihres Codes erstellen möchten, müssen Sie ihn buchstäblich kopieren / einfügen.
Mit Git haben Sie dieses Problem nicht. Ihre lokale Kopie ist ein Repository, und Sie können sich darauf festlegen und alle Vorteile der Quellcodeverwaltung nutzen. Wenn Sie die Konnektivität zum Haupt-Repository wiederherstellen, können Sie sich dagegen festlegen.
Das sieht auf den ersten Blick gut aus, aber denken Sie an die zusätzliche Komplexität dieses Ansatzes.
Git scheint das "neue, glänzende, coole" Ding zu sein. Es ist keineswegs schlecht (es gibt einen Grund, warum Linus es schließlich für die Linux-Kernel-Entwicklung geschrieben hat), aber ich habe das Gefühl, dass viele Leute in den Zug "Distributed Source Control" einsteigen, nur weil er neu ist und von Linus Torvalds geschrieben wurde, ohne dass dies tatsächlich der Fall ist zu wissen warum / ob es besser ist.
Subversion hat Probleme, aber auch Git, Mercurial, CVS, TFS oder was auch immer.
Bearbeiten: Diese Antwort ist jetzt ein Jahr alt und generiert immer noch viele positive Stimmen. Deshalb dachte ich, ich werde noch einige Erklärungen hinzufügen. Im letzten Jahr seit dem Schreiben dieses Artikels hat Git viel Schwung und Unterstützung gewonnen, insbesondere seit Websites wie GitHub wirklich in Fahrt gekommen sind. Ich benutze heutzutage sowohl Git als auch Subversion und möchte einige persönliche Einblicke geben.
Erstens kann Git bei der dezentralen Arbeit zunächst sehr verwirrend sein. Was ist eine Fernbedienung? und Wie richte ich das anfängliche Repository richtig ein? sind zwei Fragen, die am Anfang auftauchen, insbesondere im Vergleich zu SVNs einfachem "svnadmin create". Gits "git init" kann die Parameter --bare und --shared annehmen, was der "richtige" Weg zu sein scheint, eine Zentralisierung einzurichten Repository. Es gibt Gründe dafür, aber es erhöht die Komplexität. Die Dokumentation des Befehls "checkout" ist für Leute, die umsteigen, sehr verwirrend - der "richtige" Weg scheint "git clone" zu sein, während "git checkout" die Zweige zu wechseln scheint.
Git leuchtet WIRKLICH, wenn Sie dezentralisiert sind. Ich habe einen Server zu Hause und einen Laptop unterwegs, und SVN funktioniert hier einfach nicht gut. Mit SVN kann ich keine lokale Quellcodeverwaltung haben, wenn ich nicht mit dem Repository verbunden bin (Ja, ich kenne SVK oder Möglichkeiten zum Kopieren des Repos). Bei Git ist das sowieso der Standardmodus. Es ist jedoch ein zusätzlicher Befehl (git commit schreibt lokal fest, während git push origin master den Master-Zweig an die Fernbedienung mit dem Namen "origin" schiebt).
Wie oben gesagt: Git erhöht die Komplexität. Zwei Modi zum Erstellen von Repositorys: Auschecken vs. Klonen, Festschreiben vs. Push ... Sie müssen wissen, welche Befehle lokal und welche mit "dem Server" funktionieren (ich gehe davon aus, dass die meisten Leute immer noch ein zentrales "Master-Repository" mögen). ).
Außerdem ist das Tooling zumindest unter Windows immer noch unzureichend. Ja, es gibt ein Visual Studio AddIn, aber ich verwende immer noch git bash mit msysgit.
SVN hat den Vorteil, dass es VIEL einfacher zu erlernen ist: Es gibt Ihr Repository, alle Änderungen daran, wenn Sie wissen, wie man erstellt, festschreibt und auscheckt, und Sie bereit sind, Dinge wie Verzweigung, Aktualisierung usw. später aufzunehmen auf.
Git hat den Vorteil, dass es VIEL besser geeignet ist, wenn einige Entwickler nicht immer mit dem Master-Repository verbunden sind. Außerdem ist es viel schneller als SVN. Und nach allem, was ich höre, ist die Verzweigungs- und Zusammenführungsunterstützung viel besser (was zu erwarten ist, da dies die Hauptgründe sind, warum sie geschrieben wurde).
Dies erklärt auch, warum es im Internet so viel Aufsehen erregt, da Git perfekt für Open Source-Projekte geeignet ist: Fork es einfach, übertrage deine Änderungen auf dein eigenes Fork und fordere dann den ursprünglichen Projektbetreuer auf, deine Änderungen abzurufen. Mit Git funktioniert das einfach. Probieren Sie es wirklich auf Github aus, es ist magisch.
Was ich auch sehe, sind Git-SVN-Bridges: Das zentrale Repository ist ein Subversion-Repo, aber Entwickler arbeiten lokal mit Git und die Bridge überträgt ihre Änderungen dann auf SVN.
Aber auch mit dieser langen Ergänzung stehe ich zu meiner Kernbotschaft: Git ist nicht besser oder schlechter, es ist einfach anders. Wenn Sie die Notwendigkeit einer "Offline-Quellcodeverwaltung" haben und bereit sind, zusätzliche Zeit damit zu verbringen, diese zu lernen, ist dies fantastisch. Wenn Sie jedoch eine streng zentralisierte Quellcodeverwaltung haben und / oder Schwierigkeiten haben, die Quellcodeverwaltung einzuführen, weil Ihre Mitarbeiter nicht interessiert sind, dann glänzen die Einfachheit und die hervorragenden Werkzeuge (zumindest unter Windows) von SVN.
Mit Git können Sie praktisch alles offline erledigen, da jeder sein eigenes Repository hat.
Das Erstellen von Zweigen und das Zusammenführen von Zweigen ist wirklich einfach.
Auch wenn Sie keine Festschreibungsrechte für ein Projekt haben, können Sie Ihr eigenes Repository online haben und "Push-Anforderungen" für Ihre Patches veröffentlichen. Jeder, der Ihre Patches mag, kann sie in sein Projekt einbeziehen, einschließlich der offiziellen Betreuer.
Es ist trivial, ein Projekt zu verzweigen, zu ändern und die Bugfixes aus dem HEAD-Zweig weiterhin zusammenzuführen.
Git funktioniert für die Linux-Kernel-Entwickler. Das heißt, es ist sehr schnell (muss es sein) und lässt sich auf Tausende von Mitwirkenden skalieren. Git benötigt außerdem weniger Speicherplatz (bis zu 30-mal weniger Speicherplatz für das Mozilla-Repository).
Git ist sehr flexibel, sehr TIMTOWTDI (es gibt mehr als einen Weg, dies zu tun). Sie können jeden gewünschten Workflow verwenden, und Git wird ihn unterstützen.
Schließlich gibt es GitHub , eine großartige Website zum Hosten Ihrer Git-Repositories.
Nachteile von Git:
Andere Antworten haben die Kernfunktionen von Git (die großartig sind) gut erklärt. Aber es gibt auch so viele kleine Möglichkeiten, wie Git sich besser verhält und mein Leben vernünftiger hält. Hier sind einige der kleinen Dinge:
git mvund git rm.
" Warum Git besser ist als X " beschreibt die verschiedenen Vor- und Nachteile von Git gegenüber anderen SCMs.
Kurz:
Es gibt einige Nachteile:
In der einfachsten Verwendung sind Subversion und Git ziemlich gleich. Es gibt keinen großen Unterschied zwischen:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
und
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Wo Git wirklich glänzt, verzweigt sich und arbeitet mit anderen Menschen zusammen.
Google Tech Talk: Linus Torvalds über Git
http://www.youtube.com/watch?v=4XpnKHJAok8
Die Vergleichsseite des Git-Wikis
Nun, es ist verteilt. Benchmarks zeigen an, dass es erheblich schneller ist (aufgrund seiner verteilten Natur sind Vorgänge wie Unterschiede und Protokolle alle lokal, daher ist es in diesem Fall natürlich unglaublich schneller), und Arbeitsordner sind kleiner (was mich immer noch beeindruckt).
Wenn Sie auf Subversion arbeiten, oder einem anderen Client / Server - Versionskontrollsystem, erstellen Sie im Wesentlichen Kopien auf Ihrem Rechner arbeiten mit Check-out Revisionen. Dies ist eine Momentaufnahme des Repositorys. Sie aktualisieren Ihre Arbeitskopie über Updates und das Repository über Commits.
Mit einer verteilten Versionskontrolle haben Sie keinen Snapshot, sondern die gesamte Codebasis. Willst du einen Diff mit einer 3 Monate alten Version machen? Kein Problem, die 3 Monate alte Version befindet sich noch auf Ihrem Computer. Dies bedeutet nicht nur, dass die Dinge viel schneller sind, sondern wenn Sie von Ihrem zentralen Server getrennt sind, können Sie dennoch viele der gewohnten Vorgänge ausführen. Mit anderen Worten, Sie haben nicht nur eine Momentaufnahme einer bestimmten Revision, sondern die gesamte Codebasis.
Sie würden denken, dass Git eine Menge Platz auf Ihrer Festplatte beanspruchen würde, aber von ein paar Benchmarks, die ich gesehen habe, dauert es tatsächlich weniger. Frag mich nicht wie. Ich meine, es wurde von Linus gebaut, er weiß ein oder zwei Dinge über Dateisysteme, denke ich.
Die wichtigsten Punkte, die ich an DVCS mag, sind folgende:
Der Hauptgrund für ein relativ großes Projekt ist die durch Punkt 3 geschaffene verbesserte Kommunikation. Andere sind nette Boni.
Das Lustige ist: Ich hoste Projekte in Subversion Repos, greife aber über den Befehl Git Clone darauf zu.
Bitte lesen Sie Entwickeln mit Git in einem Google Code-Projekt
Obwohl Google Code nativ Subversion spricht, können Sie Git während der Entwicklung problemlos verwenden. Die Suche nach "git svn" legt nahe, dass diese Praxis weit verbreitet ist, und wir empfehlen Ihnen auch, damit zu experimentieren.
Die Verwendung von Git in einem Svn-Repository bietet mir folgende Vorteile:
backup/public SVN-Repository, das andere auschecken könnenAlle Antworten hier sind erwartungsgemäß programmiererorientiert. Was passiert jedoch, wenn Ihr Unternehmen die Revisionskontrolle außerhalb des Quellcodes verwendet? Es gibt viele Dokumente, die kein Quellcode sind, die von der Versionskontrolle profitieren und in der Nähe des Codes und nicht in einem anderen CMS leben sollten. Die meisten Programmierer arbeiten nicht isoliert - wir arbeiten für Unternehmen als Teil eines Teams.
Vergleichen Sie vor diesem Hintergrund die Benutzerfreundlichkeit von Subversion und git sowohl bei Client-Tools als auch bei Schulungen. Ich kann kein Szenario sehen, in dem ein verteiltes Revisionskontrollsystem einfacher zu verwenden oder einem Nicht-Programmierer zu erklären ist. Ich würde gerne als falsch erwiesen werden, weil ich dann in der Lage wäre, Git zu bewerten und tatsächlich die Hoffnung zu haben, dass es von Leuten akzeptiert wird, die eine Versionskontrolle benötigen und keine Programmierer sind.
Selbst dann, wenn das Management gefragt wird, warum wir von einem zentralisierten zu einem verteilten Revisionskontrollsystem wechseln sollen, fällt es mir schwer, eine ehrliche Antwort zu geben, da wir sie nicht brauchen.
Haftungsausschluss: Ich habe mich schon früh für Subversion interessiert (um v0.29), daher bin ich offensichtlich voreingenommen, aber die Unternehmen, für die ich seitdem gearbeitet habe, profitieren von meiner Begeisterung, weil ich deren Verwendung gefördert und unterstützt habe. Ich vermute, dass dies bei den meisten Softwareunternehmen der Fall ist. Ich frage mich, wie viele Unternehmen angesichts der vielen Programmierer, die sich auf den Git-Zug stürzen, die Vorteile der Versionskontrolle außerhalb des Quellcodes verpassen werden. Selbst wenn Sie separate Systeme für verschiedene Teams haben, verpassen Sie einige der Vorteile, wie z. B. die (einheitliche) Integration der Problemverfolgung, und erhöhen gleichzeitig die Anforderungen an Wartung, Hardware und Schulung.
Subversion ist immer noch ein viel häufiger verwendetes Versionskontrollsystem, was bedeutet, dass es eine bessere Werkzeugunterstützung bietet. Sie finden ausgereifte SVN-Plugins für fast alle IDE und es stehen gute Explorer-Erweiterungen zur Verfügung (wie TurtoiseSVN). Ansonsten muss ich Michael zustimmen : Git ist nicht besser oder schlechter als Subversion, es ist anders.
Eines der Dinge an SubVersion, die mich ärgern, ist, dass es in jedem Verzeichnis eines Projekts einen eigenen Ordner ablegt, während git nur einen im Stammverzeichnis ablegt. Es ist keine so große Sache, aber kleine Dinge wie diese summieren sich.
Natürlich hat SubVersion Tortoise, was [normalerweise] sehr schön ist.
David Richards WANdisco Blog über Subversion / GIT
Das Aufkommen von GIT hat eine Reihe von DVCS-Fundamentalisten mit sich gebracht - die "Gitterons" - die alles andere als GIT für Mist halten. Die Gitterons scheinen zu glauben, dass Software-Engineering auf ihrer eigenen Insel stattfindet, und vergessen oft, dass die meisten Unternehmen nicht ausschließlich leitende Software-Ingenieure beschäftigen. Das ist in Ordnung, aber es ist nicht so, wie der Rest des Marktes denkt, und ich bin glücklich, es zu beweisen: GIT hatte auf den letzten Blick weniger als drei Prozent des Marktes, während Subversion in der Region von fünf Millionen Nutzern und etwa der Hälfte davon hat der Gesamtmarkt.
Das Problem, das wir sahen, war, dass die Gitterons (billige) Schüsse auf Subversion abfeuerten. Tweets wie „Subversion ist so [langsam / beschissen / restriktiv / riecht nicht gut / sieht mich komisch an] und jetzt habe ich GIT und [alles funktioniert in meinem Leben / meine Frau wurde schwanger / ich habe danach eine Freundin 30 Jahre Versuch / Ich habe sechs Mal am Blackjack-Tisch gewonnen. Du bekommst das Bild.
Git macht auch das Verzweigen und Zusammenführen sehr einfach. Subversion 1.5 hat gerade Merge Tracking hinzugefügt, aber Git ist immer noch besser. Mit Git ist die Verzweigung sehr schnell und günstig. Dies macht das Erstellen eines Zweigs für jedes neue Feature einfacher. Oh- und Git-Repositorys sind im Vergleich zu Subversion sehr effizient mit Speicherplatz.
Es geht um die Benutzerfreundlichkeit / Schritte, die erforderlich sind, um etwas zu tun.
Wenn ich ein einzelnes Projekt auf meinem PC / Laptop entwickle, ist Git besser, da es viel einfacher einzurichten und zu verwenden ist. Sie benötigen keinen Server und müssen beim Zusammenführen keine Repository-URLs eingeben.
Wenn es nur 2 Leute wären, würde ich sagen, dass Git auch einfacher ist, weil man einfach voneinander schieben und ziehen kann.
Sobald Sie darüber hinaus sind, würde ich mich für Subversion entscheiden, da Sie zu diesem Zeitpunkt einen "dedizierten" Server oder Standort einrichten müssen.
Sie können dies mit git genauso gut tun wie mit SVN, aber die Vorteile von git werden durch die Notwendigkeit aufgewogen, zusätzliche Schritte zur Synchronisierung mit einem zentralen Server durchzuführen. In SVN legen Sie einfach fest. In git musst du git commit und dann git push. Der zusätzliche Schritt wird einfach deshalb ärgerlich, weil Sie am Ende so viel tun.
SVN hat auch den Vorteil besserer GUI-Tools, jedoch scheint das Git-Ökosystem schnell aufzuholen, sodass ich mir langfristig keine Sorgen machen würde.
Easy Git hat eine schöne Seite, auf der die tatsächliche Verwendung von Git und SVN verglichen wird. Auf dieser Seite erhalten Sie eine Vorstellung davon, was Git im Vergleich zu SVN tun (oder leichter tun) kann. (Technisch basiert dies auf Easy Git, einem leichten Wrapper über Git.)
Git und DVCS eignen sich im Allgemeinen hervorragend für Entwickler, die unabhängig voneinander viel codieren, da jeder seinen eigenen Zweig hat. Wenn Sie jedoch eine Änderung von jemand anderem benötigen, muss sie sich zu ihrem lokalen Repo verpflichten und dann muss sie diese Änderung an Sie weiterleiten, oder Sie müssen sie von ihr abziehen.
Meine eigenen Überlegungen lassen mich auch denken, dass DVCS die Qualitätssicherung und das Release-Management erschwert, wenn Sie beispielsweise zentralisierte Releases ausführen. Jemand muss dafür verantwortlich sein, dieses Push / Pull aus dem Repository aller anderen Benutzer auszuführen, Konflikte zu lösen, die zum Zeitpunkt des ersten Festschreibens zuvor gelöst worden wären, dann den Build durchzuführen und dann alle anderen Entwickler ihre Repos neu synchronisieren zu lassen.
All dies kann natürlich mit menschlichen Prozessen angegangen werden; DVCS hat gerade etwas kaputt gemacht, das durch eine zentralisierte Versionskontrolle behoben wurde, um einige neue Annehmlichkeiten zu bieten.
Ich mag Git, weil es Kommunikationsentwicklern in einem mittleren bis großen Team tatsächlich hilft. Als verteiltes Versionskontrollsystem hilft es Entwicklern durch sein Push / Pull-System, ein Quellcode-Ökosystem zu erstellen, mit dessen Hilfe ein großer Pool von Entwicklern verwaltet werden kann, die an einem einzelnen Projekt arbeiten.
Angenommen, Sie vertrauen 5 Entwicklern und ziehen nur Codes aus ihrem Repository. Jeder dieser Entwickler verfügt über ein eigenes Vertrauensnetzwerk, aus dem er Codes abruft. Daher basiert die Entwicklung auf der Vertrauensstruktur der Entwickler, bei der die Codeverantwortung von der Entwicklergemeinschaft geteilt wird.
Natürlich gibt es noch andere Vorteile, die in anderen Antworten hier erwähnt werden.
Einige Antworten haben darauf hingewiesen, aber ich möchte zwei Punkte explizit machen:
1) Die Fähigkeit, selektive Commits durchzuführen (z. B. git add --patch ). Wenn Ihr Arbeitsverzeichnis mehrere Änderungen enthält, die nicht Teil derselben logischen Änderung sind, macht es Git sehr einfach, ein Commit durchzuführen, das nur einen Teil der Änderungen enthält. Mit Subversion ist es schwierig.
2) Die Fähigkeit, sich zu verpflichten, ohne die Änderung öffentlich zu machen. In Subversion ist jedes Commit sofort öffentlich und somit unwiderruflich. Dies schränkt die Fähigkeit des Entwicklers, "frühzeitig und häufig festzuschreiben", stark ein.
Git ist mehr als nur ein VCS. Es ist auch ein Tool zum Entwickeln von Patches. Subversion ist lediglich ein VCS.
Ich denke, Subversion ist in Ordnung ... bis Sie anfangen zu verschmelzen ... oder etwas Kompliziertes zu tun ... oder etwas zu tun, was Subversion für kompliziert hält (wie Abfragen, um herauszufinden, welche Zweige mit einer bestimmten Datei durcheinander gebracht wurden, wo tatsächlich eine Änderung vorgenommen wurde stammt, Kopieren und Einfügen zu erkennen , usw)...
Ich bin mit der erfolgreichen Antwort nicht einverstanden und sage, dass der Hauptvorteil von GIT die Offline-Arbeit ist - es ist sicherlich nützlich, aber es ist eher ein Extra für meinen Anwendungsfall. SVK kann auch offline arbeiten, es steht jedoch außer Frage, in welche ich meine Lernzeit investieren soll.
Es ist nur unglaublich leistungsfähig und schnell und - nachdem man sich an die Konzepte gewöhnt hat - sehr nützlich (ja, in diesem Sinne: benutzerfreundlich).
Weitere Informationen zu einer Zusammenführungsgeschichte finden Sie unter: Verwenden von git-svn (oder ähnlichem) * nur *, um bei einer Zusammenführung von svn zu helfen?
Dank der Tatsache, dass es nicht ständig mit einem zentralen Server kommunizieren muss, wird so ziemlich jeder Befehl in weniger als einer Sekunde ausgeführt (offensichtlich sind Git Push / Pull / Fetch langsamer, nur weil sie SSH-Verbindungen initialisieren müssen). Das Verzweigen ist viel einfacher (ein einfacher Befehl zum Verzweigen, ein einfacher Befehl zum Zusammenführen)
Ich liebe es absolut, lokale Zweige meines Quellcodes in Git verwalten zu können, ohne das Wasser des zentralen Repositorys zu verwirren. In vielen Fällen werde ich Code vom Subversion-Server auschecken und ein lokales Git-Repository ausführen, um dies zu tun. Es ist auch großartig, dass das Initialisieren eines Git-Repositorys das Dateisystem nicht überall mit einer Reihe nerviger .svn-Ordner verschmutzt.
In Bezug auf die Unterstützung von Windows-Tools behandelt TortoiseGit die Grundlagen sehr gut, aber ich bevorzuge immer noch die Befehlszeile, es sei denn, ich möchte das Protokoll anzeigen. Ich mag die Art und Weise, wie Tortoise {Git | SVN} beim Lesen von Commit-Protokollen hilft.
Dies ist die falsche Frage. Es ist allzu einfach, sich auf die Warzen von git zu konzentrieren und ein Argument dafür zu formulieren, warum Subversion angeblich besser ist, zumindest für einige Anwendungsfälle. Die Tatsache, dass git ursprünglich als Konstruktionssatz für Versionskontrollen auf niedriger Ebene konzipiert wurde und über eine barocke, auf Linux-Entwickler ausgerichtete Oberfläche verfügt, erleichtert es den heiligen Kriegen, an Bodenhaftung und wahrgenommener Legitimität zu gewinnen. Git-Befürworter schlagen die Trommel mit Millionen von Workflow-Vorteilen, die SVN-Leute für unnötig erklären. Ziemlich bald wird die gesamte Debatte als zentralisiert oder verteilt dargestellt, was den Interessen der Enterprise-SVN-Tool-Community dient. Diese Unternehmen, die in der Regel die überzeugendsten Artikel über die Überlegenheit von Subversion im Unternehmen veröffentlichen,
Aber hier ist das Problem: Subversion ist eine architektonische Sackgasse .
Während Sie Git ganz einfach nehmen und einen zentralisierten Subversion-Ersatz erstellen können, obwohl es svn mehr als doppelt so lange gibt, war svn noch nie in der Lage, auch nur das grundlegende Merge-Tracking so gut wie in Git zum Laufen zu bringen. Ein Hauptgrund dafür ist die Entwurfsentscheidung, Zweige mit Verzeichnissen gleichzusetzen. Ich weiß nicht, warum sie ursprünglich diesen Weg gegangen sind, es macht sicherlich das teilweise Auschecken sehr einfach. Leider ist es auch unmöglich, die Geschichte richtig zu verfolgen. Jetzt sollten Sie natürlich die Konventionen für das Subversion-Repository-Layout verwenden, um Zweige von regulären Verzeichnissen zu trennen, und svn verwendet einige Heuristiken, damit die Dinge für die täglichen Anwendungsfälle funktionieren. All dies ist jedoch nur ein Papier über eine sehr schlechte und einschränkende Entwurfsentscheidung auf niedriger Ebene. Die Möglichkeit, ein repository-bezogenes Diff (anstelle eines verzeichnisbezogenen Diff) durchzuführen, ist eine grundlegende und wichtige Funktionalität für ein Versionskontrollsystem und vereinfacht die Interna erheblich, sodass intelligentere und nützliche Funktionen darauf aufgebaut werden können. Sie können sehen, wie viel Aufwand in die Erweiterung der Subversion gesteckt wurde und wie weit diese von der aktuellen Ernte moderner VCS in Bezug auf grundlegende Operationen wie die Auflösung von Zusammenführungen entfernt ist.
Hier ist mein herzlicher und agnostischer Rat für alle, die immer noch glauben, dass Subversion auf absehbare Zeit gut genug ist:
Subversion wird niemals die neueren Rassen von VCS einholen, die aus den Fehlern von RCS und CVS gelernt haben. Es ist eine technische Unmöglichkeit, wenn sie das Repository-Modell nicht von Grund auf umrüsten, aber dann wäre es nicht wirklich svn, oder? Unabhängig davon, wie sehr Sie glauben, nicht über die Fähigkeiten eines modernen VCS zu verfügen, schützt Sie Ihre Unwissenheit nicht vor den Fallstricken der Subversion, von denen viele Situationen unmöglich oder in anderen Systemen leicht zu lösen sind.
Es ist äußerst selten, dass die technische Minderwertigkeit einer Lösung so eindeutig ist wie bei svn. Ich würde sicherlich niemals eine solche Meinung zu Win-vs-Linux oder Emacs-vs-vi abgeben, aber in diesem Fall ist es so Clearcut und Quellcodeverwaltung sind ein so grundlegendes Werkzeug im Arsenal des Entwicklers, dass ich der Meinung bin, dass dies eindeutig angegeben werden muss. Unabhängig von der Anforderung, svn aus organisatorischen Gründen zu verwenden, bitte ich alle svn-Benutzer, sich von ihrem logischen Verstand nicht die falsche Überzeugung aufstellen zu lassen, dass modernere VCS nur für große Open-Source-Projekte nützlich sind. Unabhängig von der Art Ihrer Entwicklungsarbeit sind Sie als Programmierer ein effektiverer Programmierer, wenn Sie lernen, wie Sie besser gestaltete VCS verwenden, sei es Git, Mercurial, Darcs oder viele andere.
Subversion ist sehr einfach zu bedienen. Ich habe in den letzten Jahren nie ein Problem gefunden oder festgestellt, dass etwas nicht wie erwartet funktioniert. Außerdem gibt es viele hervorragende GUI-Tools und die Unterstützung für die SVN-Integration ist groß.
Mit Git erhalten Sie ein flexibleres VCS. Sie können es wie SVN mit einem Remote-Repository verwenden, in dem Sie alle Änderungen festschreiben. Sie können es aber auch meistens offline verwenden und die Änderungen nur von Zeit zu Zeit in das Remote-Repository übertragen. Aber Git ist komplexer und hat eine steilere Lernkurve. Ich habe mich zum ersten Mal auf falsche Filialen festgelegt, Filialen indirekt erstellt oder Fehlermeldungen mit nicht vielen Informationen über den Fehler erhalten und wo ich mit Google suchen muss, um bessere Informationen zu erhalten. Einige einfache Dinge wie das Ersetzen von Markern ($ Id $) funktionieren nicht, aber GIT verfügt über einen sehr flexiblen Filter- und Hook-Mechanismus zum Zusammenführen eigener Skripte, sodass Sie alle benötigten und mehr Dinge erhalten, aber mehr Zeit und Lesen der Dokumentation benötigen ;)
Wenn Sie größtenteils offline mit Ihrem lokalen Repository arbeiten, haben Sie keine Sicherung, wenn auf Ihrem lokalen Computer etwas verloren geht. Mit SVN arbeiten Sie meistens mit einem Remote-Repository, das gleichzeitig mit Ihrem Backup auf einem anderen Server ist ... Git kann auf die gleiche Weise funktionieren, aber dies war nicht das Hauptziel von Linus, so etwas wie SVN2 zu haben. Es wurde für die Linux-Kernel-Entwickler und die Anforderungen eines verteilten Versionskontrollsystems entwickelt.
Ist Git besser als SVN? Entwickler, die nur einen Versionsverlauf und einen Sicherungsmechanismus benötigen, haben ein gutes und einfaches Leben mit SVN. Entwickler, die häufig mit Zweigen arbeiten, mehrere Versionen gleichzeitig testen oder größtenteils offline arbeiten, können von den Funktionen von Git profitieren. Es gibt einige sehr nützliche Funktionen wie das Verstauen, die bei SVN nicht vorhanden sind und das Leben erleichtern können. Auf der anderen Seite werden jedoch nicht alle Menschen alle Funktionen benötigen. Ich kann also die Toten von SVN nicht sehen.
Git benötigt eine bessere Dokumentation und die Fehlerberichterstattung muss hilfreicher sein. Auch die vorhandenen nützlichen GUIs sind nur selten. Dieses Mal habe ich nur 1 GUI für Linux gefunden, die die meisten Git-Funktionen (git-cola) unterstützt. Die Eclipse-Integration funktioniert, ist jedoch nicht offiziell veröffentlicht und es gibt keine offizielle Update-Site (nur einige externe Update-Sites mit regelmäßigen Builds aus dem Trunk http://www.jgit.org/updates ). Daher die derzeit am meisten bevorzugte Art, Git zu verwenden ist die Kommandozeile.
Eric Sink von SourceGear schrieb eine Reihe von Artikeln über Unterschiede zwischen verteilten und nicht verteilten Versionskontrollsystemen. Er vergleicht Vor- und Nachteile der gängigsten Versionskontrollsysteme. Sehr interessante Lektüre.
Artikel finden Sie in seinem Blog unter www.ericsink.com :
Für Leute, die nach einer guten Git-GUI suchen , ist Syntevo SmartGit möglicherweise eine gute Lösung. Es ist proprietär, aber für den nichtkommerziellen Gebrauch kostenlos, läuft unter Windows / Mac / Linux und unterstützt SVN sogar mit einer Art Git-SVN-Brücke, denke ich.
http://subversion.wandisco.com/component/content/article/1/40.html
Ich denke, es ist ziemlich sicher zu sagen, dass unter Entwicklern die SVN Vs. Das Git-Argument tobt schon seit einiger Zeit, und jeder hat seine eigene Meinung darüber, was besser ist. Dies wurde sogar in den Fragen während unseres Webinars zu Subversion im Jahr 2010 und darüber hinaus angesprochen.
Hyrum Wright, unser Open Source-Direktor und Präsident der Subversion Corporation, spricht über die Unterschiede zwischen Subversion und Git sowie über andere verteilte Versionskontrollsysteme (DVCS).
Er spricht auch über die bevorstehenden Änderungen in Subversion, wie z. B. Working Copy Next Generation (WC-NG), die seiner Meinung nach dazu führen werden, dass eine Reihe von Git-Benutzern wieder zu Subversion konvertieren.
Sehen Sie sich sein Video an und teilen Sie uns Ihre Meinung mit, indem Sie entweder diesen Blog kommentieren oder in unseren Foren posten. Die Registrierung ist einfach und dauert nur einen Moment!
Git in Windows wird jetzt recht gut unterstützt.
Schauen Sie sich GitExtensions = http://code.google.com/p/gitextensions/ an.
und das Handbuch für ein besseres Windows Git-Erlebnis.
Ich habe in letzter Zeit in Git Land gewohnt und ich mag es für persönliche Projekte, aber ich wäre nicht in der Lage, Arbeitsprojekte von Subversion zu wechseln, da sich das Denken der Mitarbeiter geändert hat, ohne dringende Vorteile. Darüber hinaus ist das größte Projekt, das wir intern durchführen, extrem abhängig von svn: externals, was, wie ich bisher gesehen habe, in Git nicht so gut und nahtlos funktioniert.
Erstens scheint die gleichzeitige Versionskontrolle ein leicht zu lösendes Problem zu sein. Es ist überhaupt nicht. Wie auch immer...
SVN ist nicht intuitiv. Git ist noch schlimmer. [sarkastische Spekulation] Dies könnte daran liegen, dass Entwickler, die schwierige Probleme wie die gleichzeitige Versionskontrolle mögen, kein großes Interesse daran haben, eine gute Benutzeroberfläche zu erstellen. [/ sarkastische Spekulation]
SVN-Unterstützer glauben, dass sie kein verteiltes Versionskontrollsystem benötigen. Das habe ich auch gedacht. Aber jetzt, wo wir ausschließlich Git verwenden, bin ich ein Gläubiger. Jetzt funktioniert die Versionskontrolle für mich UND das Team / Projekt, anstatt nur für das Projekt zu arbeiten. Wenn ich einen Zweig brauche, verzweige ich. Manchmal ist es ein Zweig, der einen entsprechenden Zweig auf dem Server hat, und manchmal nicht. Ganz zu schweigen von all den anderen Vorteilen, die ich untersuchen muss (teilweise dank des arkanen und absurden Mangels an Benutzeroberfläche, die ein modernes Versionskontrollsystem ist).
Warum ich denke, dass Subversion besser ist als Git (zumindest für die Projekte, an denen ich arbeite), hauptsächlich aufgrund seiner Benutzerfreundlichkeit und des einfacheren Workflows:
http://www.databasesandlife.com/why-subversion-is-better-than-git/