Subversion vs. CVS

Alles was sonst Nirgends passt
simcen
Posts: 333
Joined: 2003-02-12 14:35
Location: Bern, Schweiz
 

Subversion vs. CVS

Post by simcen »

Hallo Leute

Ich plane ein Config Management für XML Files aufzubauen, leider habe ich die Qual der Wahl zwischen Subversion und CVS (gibt es Alternativen?).

Folgende Seite stellt meiner Meinung nach ziemlich realistisch die Vor- und Nachteile beider Systeme gebenüber: http://www.pushok.com/soft_svn_vscvs.php

Allerdings kann ich mich noch nicht enscheiden. Ich habe einerseits gute Erfahrungen mit Subversion gemacht, vermisse aber ein anständiges Web-Frontend mit Source-Highligthing und einer flexiblen diff-Möglichkeit (diff auf einen ganzen Tree oder diff auf ein beliebigs File).

Hat jemand Erfahrungen mit einem oder beiden dieser Versionierungs-Systemen?
Kennt jemand gute Web-Frontends für Subversion/CVS, möglichst in PHP?

Danke für eure Unterstützung und Gruss
Simon
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Subversion vs. CVS

Post by Roger Wilco »

simcen wrote:Ich plane ein Config Management für XML Files aufzubauen, leider habe ich die Qual der Wahl zwischen Subversion und CVS (gibt es Alternativen?).
Muss es ein zentralisiertes VCS sein? Ansonsten würde ich git oder Mercurial vorschlagen. Ersteres wenn es nur Linux Systeme sind, letzteres wenn auch "Exoten" wie Windows ;) bedient werden sollen.
simcen wrote:Folgende Seite stellt meiner Meinung nach ziemlich realistisch die Vor- und Nachteile beider Systeme gebenüber: http://www.pushok.com/soft_svn_vscvs.php
Da hätte ich auch was: http://www.infoq.com/articles/dvcs-guide
simcen wrote:Allerdings kann ich mich noch nicht enscheiden. Ich habe einerseits gute Erfahrungen mit Subversion gemacht, vermisse aber ein anständiges Web-Frontend mit Source-Highligthing und einer flexiblen diff-Möglichkeit (diff auf einen ganzen Tree oder diff auf ein beliebigs File).
Schau dir mal Trac an. Das ist zwar vermutlich mehr, als du benötigst, aber es hat die von dir genannten Funktionen.
simcen
Posts: 333
Joined: 2003-02-12 14:35
Location: Bern, Schweiz
 

Re: Subversion vs. CVS

Post by simcen »

Roger Wilco wrote:Muss es ein zentralisiertes VCS sein? Ansonsten würde ich git oder Mercurial vorschlagen.
Ja. Ich brauche ein zentrales Repository, welches regelmässig gebackuped wird und als Master Config in Kata-Fällen gilt. Ausserdem verstehe ich noch nicht ganz, wie die Nachvollziehbarkeit (welcher User hat was geändert) in einem dezentralen System abgedeckt ist. Zum Glück habe ich den Vorteil, dass in meinem Fall jeweils nur eine Person gleichzeitig an einem Tree/Project arbeitet und so das Problem des doppelten Commits nicht vorkommen sollte. Die Flexibilität das Ding in einer homogenen Systemlandschaft unterbringen zu können, wäre schon toll. Ich kann mich aber auch auf eine UNIX-basierte Lösung festlegen.

Verstehst du etwa wie der Einsatz des RCS aussehen soll bei mir? Hab ich ev. einen Knoten und ein dezentrales RCS wäre besser?
Roger Wilco wrote:Da hätte ich auch was: http://www.infoq.com/articles/dvcs-guide
Danke für den Link!
Roger Wilco wrote:Schau dir mal Trac an. Das ist zwar vermutlich mehr, als du benötigst, aber es hat die von dir genannten Funktionen.
Danke, sieht gut aus auf den 1. Blick. Werde das mal anschauen.
User avatar
Joe User
Project Manager
Project Manager
Posts: 11183
Joined: 2003-02-27 01:00
Location: Hamburg
 

Re: Subversion vs. CVS

Post by Joe User »

Als Alternative zu Trac sei noch http://www.redmine.org/ genannt.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Subversion vs. CVS

Post by Roger Wilco »

simcen wrote:Ich brauche ein zentrales Repository, welches regelmässig gebackuped wird und als Master Config in Kata-Fällen gilt.
Das geht auch mit verteilten VCS.
simcen wrote:Ausserdem verstehe ich noch nicht ganz, wie die Nachvollziehbarkeit (welcher User hat was geändert) in einem dezentralen System abgedeckt ist.
Genauso, wie beim zentralen.
simcen wrote:Verstehst du etwa wie der Einsatz des RCS aussehen soll bei mir? Hab ich ev. einen Knoten und ein dezentrales RCS wäre besser?
Ich denke schon, dass ich dein Vorhaben verstehe. ;)
Im Prinzip nehmen sich beide Varianten bei deinem Szenario nicht viel. Das bleibt im Prinzip Geschmackssache. Interessant wird es, wenn mehrere Leute gleichzeitig an den Konfigurationsdateien arbeiten oder verschiedene Konfigurationen für Staging-Server verwaltet werden sollen.

Bei der Wahl zwischen CVS und SVN ganz klar Subversion wählen.
theomega
Userprojekt
Userprojekt
Posts: 696
Joined: 2003-01-27 14:36
 

Re: Subversion vs. CVS

Post by theomega »

Hallo Leute,
ich weiß nicht wie man sich heute noch mit Subversion oder erst recht mit CVS rumschlagen kann. Wer bei sourceforge ist oder sonst irgendwelche tools einsetzten muß die nichts anderes können, dem bleibt nichts anderes, aber wer ein bischen mehr Freiheiten hat, der sollte sich mal etwas komfortableres anschaun, entweder git oder darcs würde ich empfehlen, ich selbst fahre seit ungefähr zwei Jahren sehr gut mit Darcs, gerade mit mehreren Entwicklern, wo man mit svn noch ständig collisions produziert und manuel diese lösen muß benötigt darcs keinerlei interaktion.
Ich würde es mir also zweimal überlegen ein neues Projekt mit CVS oder SVN zu beginnen.
simcen
Posts: 333
Joined: 2003-02-12 14:35
Location: Bern, Schweiz
 

Re: Subversion vs. CVS

Post by simcen »

@Roger Wilco
Bei mir kommt es organisatorisch gesehen gar nie zu dem Fall dass gleichzeitig mehrere Leute am selben File arbeiten. Ich schaue mir trotzdem die dezentrale Variante nochmals an, danke für deinen Input.

@theomega
Wie erwähnt, plane ich ein reines Configuration Management und starte kein Entwicklerprojekt. Ausserdem sind die Konfigurationen sensitiv und dürfen nicht an die öffentlichkeit gelangen. Sourceforge kommt desshalb nicht in Frage, und wäre für mein Einsatzgebiet overkill.

Nun habe ich noch eine Strukturfrage:
- Ich habe x (Sub-?)Projekte
- Jedes Projekt hat x Releases und unabhängige Release Nummern
- Jedes Subprojekt hat sein eigenes Paket an Konfigurationsfiles

Wie baue ich die Struktur in einem RCS am besten auf, dass ich...
...die zum Projekt gehörenden Releasenummern abbilden kann
...jederzeit die neusten Konfigurationen zu einem Projekt mit Releasenummer X.Y auschecken kann
Ich stelle mir da eine Kombination aus trunk und branches vor.

Merci für eure Hilfe und Gruss
Simon
User avatar
daemotron
Administrator
Administrator
Posts: 2641
Joined: 2004-01-21 17:44
 

Re: Subversion vs. CVS

Post by daemotron »

Bei Subversion könntest Du mit Tags arbeiten, um verschiedene Projekte zu trennen. HEAD wäre dann die Basis-Konfiguration (Grundgerüst o. ö.) und für jedes Projekt kannst Du dann ein Tag setzen. Revisionsnummern vergibt svn ja von sich aus, allerdings sind die nicht an einen Tag oder Branch gebunden, sondern global pro Repository.

Wenn Dir CVS sympathischer ist, wirf doch mal einen Blick auf OpenCVS - musst allerdings noch ein bisschen Geduld mitbringen, da noch kein Release vorliegt.
theomega wrote:ich weiß nicht wie man sich heute noch mit Subversion oder erst recht mit CVS rumschlagen kann. Wer bei sourceforge ist oder sonst irgendwelche tools einsetzten muß die nichts anderes können, dem bleibt nichts anderes, aber wer ein bischen mehr Freiheiten hat, der sollte sich mal etwas komfortableres anschaun, entweder git oder darcs würde ich empfehlen, ich selbst fahre seit ungefähr zwei Jahren sehr gut mit Darcs, gerade mit mehreren Entwicklern, wo man mit svn noch ständig collisions produziert und manuel diese lösen muß benötigt darcs keinerlei interaktion.
Ich würde es mir also zweimal überlegen ein neues Projekt mit CVS oder SVN zu beginnen.
Für eine reine Verwaltung von Konfigurationsdateien tut es CVS durchaus noch. Die Schwächen von CVS (z. B. Behandlung von Verzeichnissen) sind da nicht wirklich relevant. Ich habe mir Darcs mal angeschaut - sieht für mich doch aus wie Subversion (zentrales Repository etc.) Schon allein wegen der Werkzeug-Unterstützung (Eclipse-Plugins etc.) würde ich bei zentral gesteuerten Projekten bei SVN bleiben. Interessanter finde ich da schon die Entscheidung, ob zentrales oder dezentrales VCS. Mercurial werd ich mir in nächster Zeit auf jeden Fall genauer anschauen - Git hat wieder dieses Werkzeug-Problem...
Roger Wilco
Posts: 5923
Joined: 2004-05-23 12:53
 

Re: Subversion vs. CVS

Post by Roger Wilco »

jfreund wrote:Wenn Dir CVS sympathischer ist, wirf doch mal einen Blick auf OpenCVS - musst allerdings noch ein bisschen Geduld mitbringen, da noch kein Release vorliegt.
Alter OpenBSD Fanboy. ;)
Gibt es eigentlich irgendeinen alten UNIX-Dienst, den die Jungs nicht reimplementieren?
jfreund wrote:Git hat wieder dieses Werkzeug-Problem...
Wobei das auch nur unter Nicht-Linux Systemen gilt. Gerade wenn man ein wenig mit neuen Kernelversionen bzw. Kerneltrees rumspielen will oder sich seit neuestem im Ruby/Ruby on Rails Umfeld bewegt (GitHub, anyone?), ist Git schon fast Pflicht.
User avatar
daemotron
Administrator
Administrator
Posts: 2641
Joined: 2004-01-21 17:44
 

Re: Subversion vs. CVS

Post by daemotron »

simcen wrote:[...] Ich habe einerseits gute Erfahrungen mit Subversion gemacht, vermisse aber ein anständiges Web-Frontend mit Source-Highligthing und einer flexiblen diff-Möglichkeit (diff auf einen ganzen Tree oder diff auf ein beliebigs File).
[...]
Kennt jemand gute Web-Frontends für Subversion/CVS, möglichst in PHP?
Ist zwar schon ein Weilchen her, aber hast Du Dir mal WebSVN angeschaut? OK, das Original-Template ist häßlich, aber es erfüllt alle geforderten Kriterien (Syntax-Highlighting, diff auch für Verzeichnisse, in PHP geschrieben). Richtig nett finde ich den Feed Generator, den hat Trac (leider) nicht. Hier habe ich auch einen Hinweis gefunden, wie man das häßliche Entlein ein wenig aufhübschen kann...

@Roger Wilco:
Hmm, lass mal überlegen. Nö, mir fällt so spontan keiner von den alten Diensten ein, die sie nicht neu implementiert hätten. Sorgen mache ich mir aber erst, wenn sie anfangen, Ihre eigenen Implementierungen zu reimplementieren, weil ihnen die 3-Clause BSD-Lizenz als zu restriktiv erscheint :D