nicht angemeldet
Hallo!
Nabend!
Ich habe endlich meine PHP Projekte auf CVS gebracht, doch die Entwicklung ist (bis jetzt) aufwendiger.
Das ist klar, denn zusätzlich zur Verwaltung der PHP-Dateien (hauptsächlich auf Verzeichnisebene und nach Funktionalität) ist nun noch die Versionsverwaltung hinzugekommen. Aber wenn man einmal einen lauffähigen Programmcode kaputt-optimiert hat, wird man die Vorzüge einer Versionsverwaltung zu schätzen wissen.
Früher bin ich mit putty eingestiegen, und hab' alles "on-the-fly" mit mcedit gemacht
OK, CVS ist jetzt ein wenig Aufwand, aber dafür hast du neben deinem Entwicklungsverzeichnis noch das CVS-Repository als Backup. Außerdem weißt du stets, was gerade die aktuelle Version ist. Wenn du manche Dateien direkt mit SSH auf dem Server änderst, manch andere aber lokal und vielleicht zusätzlich noch auf einem dritten Rechner oder ein weiterer Entwickler, ist das Versions-Chaos doch schon vorprogrammiert.
(als Client verwende ich leider Windows
Wieso leider? Zwingt dich irgendetwas/-jemand dazu?
und da für manche Projekte viele Komponenten erforderlich sind, ist es nicht möglich, clientseitig einen Webserver zu installieren).
Weil die Komponenten nur auf dem Server-Betriebssystem laufen oder in geschützten Verzeichnissen liegen? Tja, Samba oder NFS wäre da nicht schlecht, dann könntest du dir diese Komponenten einfach auf deine Entwicklungsmaschine mounten.
Wie arbeitet ihr/man mit CVS, bzw. was ist die vernünftigere Herangehensweise?
1.) Die Arbeiten in einer Testumgebung ausführen, mit FTP arbeiten und nur "manchmal" ein Commit durchführen.
So handhabe ich das bei den meisten Projekten, dann ist sichergestellt, dass nur lauffähige Versionen im CVS sind. Diese müssen zwar nicht zwingend stabil sein, aber immerhin gibt es keine Compiler-/Interpreter-/Laufzeit-Fehler, außer in halbwegs exotischen Situationen.
Das fände ich aber extrem lästig, denn ich habe auch sehr viele kleine Seiten dabei und für jedes Projekt eine eigene Testumgebung scheint mir zu "overloaded".
Du kannst mit CVS auch einfach das komplette Repository auschecken und hast dann -- gemäß der Verzeichnisstruktur des Projektes -- eine große Testumgebung, die die ganzen kleinen enthält.
2.) Alle Arbeiten direkt mit CVS durchführen, d.h. nach jeder Änderung ein Commit machen, auch wenn nur ein Semikolon fehlt.
Das gibt einiges an Traffic zwischen dir und dem CVS-Repository. Außerdem glaube ich, dass der CVS-Overhead dafür unverhältnismäßig groß ist. Ich denke, dass -- abgesehen von fundamentalen Änderungen und Bugfixes -- die Change-Informationen nicht größer als die eigentliche Änderung sein sollten.
So mache ich es bis jetzt mit TortoiseCVS.
Kenne ich nicht, ist das ein CVS-Client für Windows?
Gibt es irgendeinen Nachteil dabei, wenn man viele, viele Commits durchführt?
Ja, denn im Vergleich zu "guten" Versionsverwaltungen (wie z.B. subversion) speichert CVS alle Informationen über eine Datei sowie deren Inhalt in einer einzigen Datei; dies nennt man flat-file-concept. Je mehr Änderungen du machst, desto größer wird dieses flat-file und desto länger dauert das bearbeiten dieser Datei, vor allem wenn du ältere Versionen oder Neben-Branches aus- und eincheckst.
Im Prinzip finde ich ja dass es egal ist, denn erstens wird' eh immer nur die betreffende Datei übertragen und zweitens kann ich dann wirklich lückenlos *jede* Änderung nachverfolgen
Da ist was dran, aber das ganze könnte problematisch werden, wenn mehrere Leute an einer Datei arbeiten, vermute ich.
(bei anderen nicht Webprojekten habe ich eben des Öfteren vergessen, zwischendurch ein Commit zu machen und so ist die Changelog etwas unvollständig).
Sofern das nicht gravierend ist, sollte das doch nicht das Problem sein, oder?
Dazu gleich die nächsten zwei Fragen:
1.) Es gibt viele Editoren, die haben einen FTP Client eingebaut. Gibt es einen guten Editor zu empfehlen, der eingebautes CVS (over ssh) kann, mit Syntaxhighlighting und Co?
Schau mal bei https://sourceforge.net/ vorbei, würde mich wundern, wenn es so einen Editor nicht gäbe.
2.) Gibt es bei CVS die (einfache?) Möglichkeit, serverseitig nach einem Commit ein Script auszuführen? (und zwar für ein bestimmtes Projekt, einen bestimmten Benutzer, ...), sodass ich bei einem Commit gleich serverseitig automatisch ein "update" auf den Webspace machen könnte.
Das wäre ne Klasse Sache. Ich kenne keine Möglichkeit dazu, aber vielleicht sollte ich doch endlich mal das Cederqvist-Handbuch lesen.
Bis jetzt mache ich nämlich folgendes:
1.) Dateien mit _notepad.exe_ bearbeiten.
Ich habe Mitleid mit dir. Wie wär es denn -- wenn auch nur temporär -- mit einem besseren Editor, gibt ja genug davon: http://aktuell.de.selfhtml.org/links/html_editoren.htm.
2.) Commit
3.) auf dem Server cvs update ausführen, damit die Änderungen auch in der Webumgebung wirksam werden
4.) Aktualisieren im Browser, um das Ergebnis zu sehen.
Hm, wie willst du das denn noch tunen?
...und das ist eben um einiges lästiger als einfach <F2> und <ENTER> im Midnight Commander unter putty und danach nach einem <ALT>+<TAB> schnell ein <F5> im Browser...
OK, du kannst ja aber auch mit <ALT>+<TAB> zwischen dem Editor, dem CVS- sowie dem SSH-Fenster und deinem Browser hin- und herspringen.
Vielen Dank für eure Kommentare!
Peter
Bitte schön, Robert