Versionskontrolle bei Webprojekten

[Andreas Korthaus]

Hi Sven!

Die Commits werden direkt danach automatisch auf einen öffentlichen Testserver aktualisiert - dann kann der Kunde ggf. auch angucken, wie der Stand ist.
Machst Du das per "post-commit hook"?

In meiner Datei loginfo (aus CVSROOT) steht die Zeile
^modulname      (date; cat; (sleep 2; cd /var/www/vhosts; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

Das heißt aber, dass Deine öffentliche Testumgebung auch eine CVS Arbeitskopie ist, ja? Ich überlege ja, ob ich das so auch für meine eigene Testumgebung machen soll. Das dumme wenn ich immer den Weg über SVN gehe, das heißt für jeden kleinen Typo, dann sinkt I;HO auch die Qualität des Archivs, denn wenn ich eine größere Änderung mache, eine ausführliche Message dazu schreibe - und dann funktioniert es gar nicht so wie ich gehofft hatte, sondern erst 12 "triviale" commits später, dann ist das hinterher ziemlich blöd wenn man da was nachvollziehen will, oder eine Änderung rückgängig machen will. Da wo die Message der Änderung im Log steht, funktioniert das was geändert wurde dann möglicherweise noch gar nicht, eben erst die 12 Revisionen später. Nein, so kann ich das nicht machen, das ist Mist.

Alternativen hierzu wären also:

1. Zugriff auf die Dateien auf dem Testserver über SMB/FTP
2. Verwendung einer lokalen Testumgebung

Vorteil der beiden Varianten ist dass man lokal wie auf dem Testserver mit denselben Dateien arbeitet. Hm. Aber für Variante 1 habe ich lokal keine Dateien und bei 2. muss ich diese test-Umgebung auf jedem Rechner einrichten, auf dem entwickelt wird. Hm.

Man muß also den Testserver einmalig manuell auschecken (bzw. kann Branches zwischendurch ebenfalls aktualisieren), und künftig wird das immer automatisch auf dem neuesten Stand gehalten (in diesem Branch).

Mit "Testserver" meinst Du jetzt nicht den Server mit dem Du lokal testest, sondern die öffentliche Variante für den Kunden, ja?

Ich überlege gerade, ob ich vielleicht sowohl auf dem Testserver (der Server auf den ich [und *nur* ich] Scripte vom lokalen Rechner hochlade) als auch auf dem lokalen Entwicklungs-PC eine Arbeitskopie auschecken und pflegen soll. Das heißt, wenn ich anfange zu arbeiten mache ich sowohl lokal als auch remote ein svn update, arbeite dann lokal an einem Script, lade das manuell per SCP auf den Testserver, teste es im Browser, mache evtl. noch ein paar kleiner Korrekturen und wenn alles so läuft wie ich es möchte committe ich das. Die Frage ist nur - von wo aus? Ist es besser lokal, oder remote eine 100%ige Konsistenz zu haben? Ich denke eher lokal, denn da muss ich so oder so updaten wenn ich auf einem anderen Rechner arbeite. Allerdings kann es bei einem Fehler passieren (z.B. eine Datei nicht hochgeladen), dass es so aussieht als würde die Änderung funktionieren, in der nicht hochgeladenen Datei aber ein Fehler schlummert. Aber auch anders herum, wenn ich remote committe habe ich das Problem, dass vielleicht irgendwelche lokalen Änderungen nicht ins System wandern.

Gut, im Normalfall sollte sowas nicht passieren, aber verlassen kann man sich darauf eben nicht - im Gegensatz zu den von Euch verwendeten Methoden.

Gut, dann wird es wohl darauf hinauslaufen, dass ich nach einem (lokalen) commit nochmal remote einen export mit --force Switch durchführe, um alles zu überschreiben, und das dann alles nochmal teste. Das kann ja auch automatisiert passieren. Oh Gott - wirklich "schön" ist diese Vorgehensweise wohl nicht... ;-)

Und Releases installiere ich ebenfalls direkt per CVS-Zugriff auf dem Live-Server.
Das machst Du dann per "export"?

Manuell remote auf der Shell. :)

Ja, meine ich ja, bei SVN wäre das svn export....

Weißt Du wie man bei SVN oder CVS eine Datei von commits ausnimmt? Z.B. eine angepasste Konfigurationsdatei (die im Repository mit default-Werten existiert)...

Grüße
Andreas