Hi uli,
Gibt es PHP-basierte CVS? oder muss ich auf meinem
Linuxserver da eines installieren?
CVS ist ein typisches UNIX-Produkt: Es funktioniert so
ähnlich wie eine Zwiebel. ;-)
Ganz innen drin ist ein Baustein, der sich RCS nennt
(revisions control system). Das ist der elementare
Versions-Verwalter: Der kann Dateien ein- und aus-
checken, Versionsnummern vergeben und verstehen und
ähnliche Dinge. RCS speichert Versionen einer Datei
mit einer Differenzen-Methode - ein Archiv einer
Datei enthält also die gesamte Änderungs-Historie,
ohne dadurch ein Vielfaches der Größe der letzten
Version zu haben.
Auf der Ebene einzelner Dateien kann man mit RCS
alleine schon sinnvoll arbeiten - komfortabel ist
es allerdings nicht.
CVS ist dann bereits eine Schicht drüber, die ein in-
stalliertes RCS als System-Kommandos benutzt. CVS
versteht nun Dinge wie "Projekte" und Projektverzeich-
nisse.
Mit CVS kann ein Anwender ein komplettes Projekt (einen
Verzeichnisbaum) "aus-checken", d. h. sich eine Kopie
des Baums der aktuellen (oder der als Parameter ange-
gebenen) Version aller Dateien eines Projekts anlegen.
In jedem Verzeichnis legt CVS ein Unterverzeichnis mit
dem Namen "CVS" an, welches Verwaltungsinformationen
enthält - beispielsweise: Welche Version welcher Datei
habe ich ausgecheckt, und welches Änderungsdatum hatte
die damals? Auf diese Weise kann CVS feststellen, ob
und in welchem Umfang Du etwas an der aktuellen Kopie
geändert hast. Beispielsweise steht dort auch drin,
welche Dateien des jeweiligen Verzeichnisses überhaupt
zum Projekt gehören - andere Dateien im selben Ver-
zeichnis werden ignoriert. ("cvs add <dateiname>" fügt
eine Datei der Menge der "projektdateien" hinzu.)
Das Wurzelverzeichnis des Projekt-Archivs findet CVS
über eine Environment-Variable der Shell. Aus diesem
und dem aktuellen Verzeichnis bastelt sich CVS die
Pfadnamen zusammen, mit denen es die jeweiligen RCS-
Kommandos aufruft, welche die eigentliche Arbeit tun.
Andere Entwickler am selben Projekt können zeitgleich
ebenfalls eine ausgecheckte Kopie haben. Beim Ein-
checken kannst Du einzelne Dateien angeben oder auch
"alles" festschreiben lassen - CVS prüft dann erst mal,
ob die von Dir ausgecheckten Versionen mit den inzwi-
schen im Archiv vorhandenen Versionen identisch sind,
also ob Dein "checkin" von demjenigen Stand ausgeht,
der inzwischen der aktuelle ist. Falls nicht, bekommst
Du entsprechende Meldungen und mußt erst mal Deine
lokalen Änderungen mit denen, die andere Leute an den-
selben Dateien im Archiv vorgenommen haben, manuell
zusammenführen - vorher kannst Du nicht alles committen
(und das ist auch der Sinn der Sache).
Die Idee dabei ist, daß mehrere Entwickler meistens an
disjunkten Teilen des Projektes arbeiten, so daß es
reicht, wenn die tatsächlich auftretenden Kollisionen
bemerkt werden - auflösen muß man sie selbst.
Die nächste Zwiebelschale drüber ist dann eine Web-
Oberfläche, welche die Kommandos des CVS-Produkts auf-
ruft und deren Ausgaben in HTML-Dokumente umsetzt.
SourceForge nutzt so etwas beispielsweise:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mod-gzip/mod-gzip13x/ ist der CVS-Lese-Zugang zum Quelltext von mod_gzip 1.3. Du kannst
dort in der Historie der Quelltexte blättern, und
Operationen durchführen wie "welche Zeilen haben sich
zwischen Version 1.18 und 1.19 geändert? Auf der Ebene
von CVS ist das ein Systemkommando der Art "cvs diff
-r11.18 -r21.19" - die Web-Schicht darüber fängt die
Ausgabe auf und macht eine farbige Tabelle daraus:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mod-gzip/mod-gzip13x/mod_gzip.c.diff?r1=1.18&r2=1.19
Welche Erfahrungen habt ihr mit cvs
Ich habe in der Firma ein Projekt mit einer Viertel-
million lines of code mit CVS abgewickelt - unsere
Mitterfirma eines mit der vierfachen Größe.
und könnt ihr mir Produkte empfehlen?
CVS ist 'das Produkt'.
Welche 'Ausbaustufe' Du haben willst, hängt von Deinem
Arbeitsstil ab. Wenn Du gewohnt bist, auf einer Kom-
mandozeile zu arbeiten, dann reicht das normale CVS-
Paket, das ähnlich zu installieren ist wie der GNU-C-
Compiler.
Das Kommando "cvs" selbst erklärt seine Optionen; die
Dokumentation wird in Form von manpages mitgeliefert.
Wie man dann sinnvoll Projekte anlegt usw., das mußt
Du natürlich durchlesen.
Ich habe mir damals Shell-Skripte "do_<projektname>"
geschrieben, welche als Shell-Alias-Funktionen mein
Environment so eingestellt haben, daß ich anschließend
mit CVS in diesem Projekt arbeiten konnte:
- Environment-Variable auf das Archiv gesetzt,
- "cd" ins Wurzelverzeichnis der ausgecheckten Kopie,
- PATH so gesetzt, daß das bin-Verzeichnis dieses
Projekts drin war
und ähnliche Kleinigkeiten.
Die Entwickler mußten dann über nichts mehr nachdenken - die brauchten nur noch "cvs checkout", "cvs commit"
und "cvs diff" verstanden zu haben.
Mit der Web-Schicht drüber habe ich noch nicht aktiv
(als committer) gearbeitet - bei mod_gzip nutze ich
sie bisher nur zum Lesen.
Viele Grüße
Michael