Mein Unternehmen verwendet CVS als De-facto-Standard für die Versionskontrolle. Ich habe jedoch von vielen Leuten gehört, dass SVN besser ist.
Ich weiß, dass SVN neuer ist, aber abgesehen davon kenne ich seine Vorteile nicht.
Was ich suche, ist ein guter, prägnanter Vergleich der beiden Systeme, der alle Vor- und Nachteile der beiden Systeme in einer Java/Eclipse-Entwicklungsumgebung aufzeigt.
CVS verfolgt Änderungen nur dateiweise, während SVN einen ganzen Commit als neue Revision verfolgt, was bedeutet, dass es einfacher ist, die Geschichte Ihres Projekts zu verfolgen. Hinzu kommt, dass alle modernen Versionskontrollprogramme das Konzept der Revision verwenden, so dass es viel einfacher ist, von SVN zu migrieren als von CVS.
Außerdem gibt es das Problem der atomaren Übertragung. Ich bin zwar nur ein einziges Mal darauf gestoßen, aber es ist möglich, dass zwei Personen, die gemeinsam in CVS übertragen, in Konflikt miteinander geraten, wodurch einige Daten verloren gehen und Ihr Client in einen inkonsistenten Zustand versetzt wird. Wenn diese Probleme frühzeitig erkannt werden, sind sie nicht so gravierend, da die Daten noch irgendwo da draußen sind, aber in einer stressigen Umgebung kann das ein Problem sein.
Und schließlich werden nicht mehr viele Werkzeuge rund um CVS entwickelt. Während es den neuen und glänzenden Tools wie Git oder Mercurial definitiv an Tools fehlt, hat SVN eine ziemlich große Anwendungsbasis auf jedem System.
EDIT 2020 : Ernsthaft, diese Antwort ist jetzt 12 Jahre alt. Vergessen Sie SVN, verwenden Sie Git wie jeder andere auch!
"Vergessen Sie SVN, verwenden Sie Git": Ich glaube nicht, dass das eine Frage von alt/neu ist oder davon, wie viele Leute es benutzen, das sind verschiedene Dinge
Einer der vielen Vergleiche:
http://wiki.scummvm.org/index.php/CVS_vs_SVN
Das ist zwar sehr spezifisch für dieses Projekt, aber vieles davon gilt auch allgemein.
Pro Subversion:
- Unterstützung für versionierte Umbenennungen/Verschiebungen (unmöglich mit CVS): Fingolfin, Ender
- Unterstützt Verzeichnisse von Haus aus: Es ist möglich, sie zu entfernen, und sie sind versioniert: Fingolfin, Ender
- Dateieigenschaften sind versioniert; keine "ausführbare Bit"-Hölle mehr: Fingolfin
- Die allgemeine Revisionsnummer erleichtert die Versionskontrolle und Regressionstests: Ender, Fingolfin
- Atomare Übertragungen: Fingolfin
- Intuitive (verzeichnisbasierte) Verzweigung und Kennzeichnung: Fingolfin
- Einfachere Hook-Skripte (Pre-/Post-Commit, etc.): SumthinWicked (ich verwende es für Doxygen nach Übertragungen)
- Verhindert das versehentliche Übertragen von Dateien mit Konflikten: Salzwasserpferd, Fingolfin
- Unterstützung für benutzerdefinierten 'diff'-Befehl: Fingolfin
- Offline-Diffs, und sie sind sofort: sev
Das Subversion-Buch hat einen Anhang die wichtige Unterschiede zum CVS aufzeigt, die Ihnen bei Ihrer Entscheidung helfen können. Die beiden Ansätze sind mehr oder weniger die gleiche Idee, aber SVN wurde speziell entwickelt, um lange bestehende Fehler in CVS zu beheben, so dass SVN zumindest theoretisch immer die bessere Wahl sein wird.
Ich schließe mich Eridius' Vorschlag von Git an, würde ihn aber auf die anderen DRCS (Distributed Revision Control System) ausweiten, wie z.B. Mercurial y Basar .
Diese Produkte sind relativ neu und das Niveau der Werkzeuge und der Integration mit ihnen scheint im Moment niedrig zu sein (basierend auf meinen ersten Recherchen). Ich würde sagen, sie sind am besten für die Power-Entwickler da draußen (und hier ;-)) geeignet.
Andererseits, was nicht CVS derzeit für Sie tun? Aus Ihrer anfänglichen Frage geht hervor, dass Sie nicht wirklich ein "CVS ist scheiße, was könnte ich stattdessen nutzen?" haben.
Sie müssen die Kosten einer möglichen Migration gegen die Vorteile abwägen. Bei einem bestehenden Projekt wäre dies meiner Meinung nach schwer zu rechtfertigen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
