Frage

Mein Unternehmen verwendet CVS als unseren De-facto-Standard für die Quellcodeverwaltung.Allerdings habe ich viele Leute sagen hören, dass SVN besser ist.

Ich weiß, dass SVN neuer ist, aber ansonsten kenne ich seine Vorteile nicht.

Was ich suche, ist ein guter, prägnanter Vergleich der beiden Systeme, wobei alle Vor- und Nachteile jedes einzelnen in einer Java/Eclipse-Entwicklungsumgebung aufgeführt werden.

War es hilfreich?

Lösung

CVS verfolgt Änderungen nur Datei für Datei, während SVN einen gesamten Commit als neue Revision verfolgt, was bedeutet, dass Sie den Verlauf Ihres Projekts einfacher verfolgen können.Hinzu kommt, dass alle moderne Versionsverwaltungssoftware das Konzept der Revision verwendet, sodass die Migration von SVN weitaus einfacher ist als von CVS.

Es gibt auch das Atomic-Commit-Problem.Ich bin zwar nur einmal darauf gestoßen, aber es ist möglich, dass zwei Personen, die sich gemeinsam in CVS verpflichten, miteinander in Konflikt geraten, einige Daten verlieren und Ihren Client in einen inkonsistenten Zustand versetzen.Wenn diese Probleme frühzeitig erkannt werden, sind sie nicht schwerwiegend, da Ihre Daten immer noch irgendwo da draußen sind. In einer stressigen Umgebung können sie jedoch mühsam sein.

Und schließlich werden nicht mehr viele Tools rund um CVS entwickelt.Während es den neuen und brandneuen Tools wie Git oder Mercurial definitiv noch an Tools mangelt, verfügt SVN über eine ziemlich große Anwendungsbasis auf jedem System.

BEARBEITEN 2015:Im Ernst, diese Antwort ist jetzt 7 Jahre alt.Vergessen Sie SVN, nutzen Sie Git wie alle anderen!

Andere Tipps

Einer der vielen Vergleiche:

http://wiki.scummvm.org/index.php/CVS_vs_SVN

Das ist zwar sehr spezifisch für dieses Projekt, aber viele Dinge gelten auch allgemein.

Pro-Subversion:

  • Unterstützung für versionierte Umbenennungen/Verschiebungen (mit CVS nicht möglich):Fingolfin, Ender
  • Unterstützt Verzeichnisse nativ:Sie können entfernt werden und sind versioniert:Fingolfin, Ender
  • Dateieigenschaften sind versioniert;kein „ausführbares Bit“ mehr zur Hölle:Fingolfin
  • Die allgemeine Revisionsnummer erleichtert die Erstellung von Build-Versionen und Regressionstests erheblich:Ender, Fingolfin
  • Atomare Commits:Fingolfin
  • Intuitives (verzeichnisbasiertes) Verzweigen und Tagging:Fingolfin
  • Einfachere Hook-Skripte (Pre/Post-Commit usw.):SumthinWicked (ich verwende es für Doxygen nach Commits)
  • Verhindert das versehentliche Festschreiben von Konfliktdateien:Salziges Pferd, Fingolfin
  • Unterstützung für den benutzerdefinierten „diff“-Befehl:Fingolfin
  • Offline-Unterschiede, und sie sind sofort verfügbar:schwer

SVN hat gegenüber CVS drei Hauptvorteile

  • es ist schneller
  • unterstützt die Versionierung von Binärdateien
  • und fügt transaktionales Commit hinzu (alles oder nichts)

Das Subversion-Buch hat ein Anhang Darin werden wichtige Unterschiede zu CVS aufgeführt, die Ihnen bei Ihrer Entscheidung helfen können.Bei den beiden Ansätzen handelt es sich mehr oder weniger um die gleiche Idee, aber SVN wurde speziell entwickelt, um seit langem bestehende Fehler in CVS zu beheben, sodass SVN zumindest theoretisch immer die bessere Wahl sein wird.

Ich werde Eridius' Vorschlag von Git unterstützen, aber ich würde ihn auf das andere DRCS (Distributed Revision Control System) erweitern, wie z Mercurial Und Basar.

Diese Produkte sind relativ neu und der Grad der Tools und Integration mit ihnen scheint derzeit gering zu sein (basierend auf meinen ersten Recherchen).Ich würde sagen, dass sie am besten für die Power-Entwickler da draußen (und hier ;-)) geeignet sind.

Andererseits, was nicht Was macht CVS derzeit für Sie?Aus Ihrer ersten Frage geht hervor, dass Sie nicht wirklich eine Frage haben: „CVS ist darin scheiße, was könnte ich stattdessen verwenden?“

Sie müssen die Kosten einer möglichen Migration gegen den Nutzen abwägen.Für ein bestehendes Projekt wäre es meiner Meinung nach schwer zu rechtfertigen.

Eine Sache, die man nicht übersehen sollte, ist das Ökosystem.Ich habe in einem CVSNT-Shop gearbeitet und festgestellt, dass immer mehr Open-Source-Tools SubVersion standardmäßig unterstützen.

Übrigens:CVSNT unterstützt atomare Commits

Als jemand, der gerade dabei ist, zwischen CVS und SVN zu wechseln (zunächst haben wir alle unsere Projekte mit cvs2svn umgestellt und dann beschlossen, dass wir bei der Umstellung nur SVN für neue Projekte verwenden würden), sind hier einige der Probleme, die wir hatten.

  • Zusammenführen und Verzweigen sind sehr unterschiedlich, und wenn Sie häufig verzweigen und zusammenführen, müssen Sie wissen, wann Sie verzweigt haben, es sei denn, Sie haben SVN 1.5 auf Ihrem Server ausgeführt (dies ist in den Tortoise SVN-Dialogen nicht ganz klar).Michael sagt, das Verzweigen und Zusammenführen sei intuitiv, ich würde behaupten, dass dies nach 10 Jahren Verwendung von CVS nicht der Fall ist.
  • Wenn Sie den SVN-Server unter Linux ausführen, kann es schwierig sein, Ihre SA auf SVN 1.5 umzustellen, da die Standardinstallation 1.4.x ist.
  • Das Zusammenführen von Konflikten ist in TortoiseSVN bei weitem nicht so einfach oder klar (zumindest für mich und meine Kollegen) wie in TortoiseCVS.Der Drei-Fenster-Ansatz ist gewöhnungsbedürftig und WinMerge (mein bevorzugtes Zusammenführungstool) führt keine Drei-Fenster-Zusammenführung durch.
  • In acht nehmen:Da viele der Online-Tutorials und Zeitschriftenartikel, die ich gelesen habe, offensichtlich nicht verzweigen und zusammenführen, sollten Sie Ihr Haupt-Repository als einrichten https://svn.yoursvnserver.com/repos/YourProject/Trunk und verzweigt sich weiter https://svn.yoursvnserver.com/repos/YourProject/Branches/BranchX .Sie können aufräumen, wenn Sie Ihre Repos an der falschen Stelle starten, aber das führt zu Verwirrung.

Schauen Sie sich das mal an Git anstelle von SVN.Es ist ein DVCS, das rasend schnell und sehr leistungsstark ist.Es ist nicht so benutzerfreundlich wie SVN, aber es verbessert sich in dieser Hinsicht, und das ist auch nicht der Fall Das schwierig zu lernen.

CVS (Concurrent Versions System) und SVN (SubVersioN) sind zwei Dateisysteme zur Versionskontrolle, die häufig von Teams verwendet werden, die an einem einzelnen Projekt zusammenarbeiten.Mit diesen Systemen können die Mitarbeiter die vorgenommenen Änderungen verfolgen und wissen, wer was entwickelt und ob ein Zweig auf den Hauptstamm angewendet werden sollte oder nicht.CVS ist das viel ältere der beiden und für viele Menschen das Standardtool für die Zusammenarbeit.SVN ist viel neuer und führt viele Verbesserungen ein, um den Anforderungen der meisten Menschen gerecht zu werden.

Sie können sich auch dafür entscheiden, nur den neuesten Code von CVS in SVN zu migrieren und Ihr aktuelles CVS-Repository einzufrieren.Dies erleichtert die Migration und Sie können Ihre Legacy-Releases möglicherweise auch im alten CVS-Repo erstellen.

Nun, ein paar Dinge, die meiner Meinung nach SVN großartig machen.

  1. Die SVN-Altassianische Tiegelkombination ist eine weit überlegene Methode zur Überprüfung und Qualitätskontrolle
  2. Besseres Management von Konflikten und Zusammenführungen
  3. Es ist offensichtlich schneller, wenn Sie zur Kasse gehen, Commits durchführen usw.
  4. Das Problem des atomaren Commits – Es ist möglich, dass zwei Personen, die gemeinsam in CVS Commits durchführen, miteinander in Konflikt geraten, einige Daten verlieren und Ihre Codebasis in einen inkonsistenten Zustand versetzen

Die Migration kann mit cvs2svn problemlos in wenigen Stunden durchgeführt werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top