Werkzeug gesucht: Editor, Repository, Zeitplanung, etc.

[Sven Rautenberg]

Moin!

Wie sieht das jetzt praktisch aus, wenn ich ein Script von meinem PHP-Projekt austauschen will, das heißt ich mache lokal eine Änderung und will das dann auf dem Server testen. Normalerweise überschreibe ich dann die alte Version, aber wie geht das bei CVS? Soweit ich das verstanden habe greift der Webserver ja nicht auf das Repository zu, also wie bekomme ich die Änderungen die ich jetzt meinetwegen im CVS eingecheckt habe auf den Webserver(in dessen Document Root), also dass dieser das aktuelle Dokument hat?

Der Webserver checkt ebenfalls eine Kopie aus dem Repository aus und arbeitet mit dieser.

Das hat den Vorteil, dass man die auf dem Server aktive Version genauer regeln kann. Wenn man (was sinnvoll ist - siehe das verlinkte CVS-Buch) mit Tags und Branches arbeitet, dann kann man beispielsweise einen Entwicklungsstand, der funktioniert und Bugfrei ist, "releasen". Also ein Tag auf den aktuellen Stand setzen, und einen Branch an der Stelle definieren, und diesen Branch dann auschecken und auf den Server packen.

Die Entwicklung geht dann irgendwie weiter. Neue Features werden in der Hauptlinie eingebracht und committet. Ein CVS-Update der Webserverkopie aber wird diese Änderungen _nicht_ einbeziehen, da dort der Branch ausgecheckt wurde.

Bugfixes im Branch hingegen gelangen auf den Webserver.

Auf diese Weise kann man eigentlich ganz passabel arbeiten. Und man kann (sofern CVS-Server und Testumgebungs-Webserver eine Maschinen sind) auch konfigurieren, dass Updates im CVS automatisch auf den Webserver ausgecheckt werden und direkt sichtbar werden.

Ich habe für mich als Entwicklungsumgebung folgende Konstruktion:
1. Eine lokale CVS-Kopie aus dem Repository in einem Verzeichnis.
2. Auf diesem Rechner ist lokal auch Apache, PHP, MySQL etc. installiert, das CVS-Verzeichnis ist auf diese Weise direkt testbar, wenn ich mit dem Editor was in meiner Kopie ändere.
3. Wenn die Änderungen, die ich gemacht habe, funktionieren, werden sie auf den CVS-Server ins Repository eingespielt.
4. Auf dem CVS-Server ist ebenfalls eine CVS-Kopie, welche, genau wie bei mir lokal, von dem Webserver ausgeliefert werden kann. Dieser Webserver ist öffentlich erreichbar (dann können Teammitglieder und der Kunde den Entwicklungsstand bzw. den Release-Stand sehen) und wird automatisch aktualisiert. Es ist kein Problem, mehrere CVS-Kopien aus mehreren Branches parallel in verschiedenen virtuellen Hosts zu haben. Also eine, die den aktuellen, neuesten Stand zeigt, für intern, und eine, die den letzten Release plus aktuelle Bugfixes des verwendeten Branches zeigt.
5. Wenn man Shell-Zugang zum Kundenserver hat, installiert man auch dort CVS als Kommandozeile und kann sich direkt vom eigenen CVS-Server das aktuelle Release und die jeweiligen Updates ziehen.

Ich finde das alles ingesamt sehr komfortabel. Die CVS-Kommandozeile ist nicht so kompliziert, wie man auf den ersten Blick vermutet. Ein CVS-Update beschränkt sich meist auf "cvs -q update" - das war's. Eine CVS-Kopie merkt sich nämlich, woher sie gekommen ist, und wird künftig immer wieder von dieser Position aus Updates ziehen.

- Sven Rautenberg