Albrecht Weinert Labor für Medien und verteilte Anwendungen Fachbereich Elektrotechnik und Informatik (FB3) der Hochschule Bochum Tipps zu CVS für Windows -- cvsNT ======================================= Stand V01.00, 05.12.2005: neu (aus subversion-install-tipp.txt) V01.02, 11.12.2005: Überarb. nach Installation durch weitere Nutzer V01.02, 13.12.2005: Back-Up-Verfahren (erprobt und) ergänzt V01.06, 27.12.2005: Neues Projekt (gründlich) korrigiert (Anh. D) V.22 02.12.2008: Versionssprung wegen CVS > SVN V.22++ 07.12.2008: kl. Korr und Erg. V.039+ 08.08.2009: Eclipse Rechtschreibhilfe (http://ai2t.de/public/eclipse/de_DE.dic) V.333+ 14.09.2016: keine inhaltliche Änderung. cvsNT bleibt Stand 2009 Version V1 (23.09.2016) Copyright (c) 2006 Albrecht Weinert a-weinert.de All rights reserved. Inhalt: 1. Zweck, Voraussetzungen 2. Server - Installation 3. Client - Installation und Server - Nacharbeit 4. Übernahme eines (alten) CVS-Projekts 5. Einrichten eines Projekts (Moduls) 6. Sichern der Projekte (Backup) 7. Zum Export 8. Rename -- Fallen 9. Anhang A: CVS Wrapper (für Windows) B: "Schöne" keyword-substitution C: Back-Up-Skript D: Add-All-Skript 1. Zweck, Voraussetzungen ~~~~~~~~~~~~~~~~~~~~~~ Das im folgenden beschriebene Vorgehen zeigt Ihnen, wie Sie den * Versionskontroll-Dienst -- Concurrent Versioning System -- CVS für Windows auf einem Windows-Server installieren und mit Windows-Clients benutzen. Mit CVS für Windows ist cvsNT, die freeware von March Hare Pty Ltd, gemeint. Diese Windows-Version beseitigt (endlich) Mängel, die für halbherzig nach Windows portierte Unix-/Linux-Programme so typisch und lästig sind: - 7-Bit-Zeichensätze, - keine Dateirechte mit access control lists (d.h keine ACLs, sondern nur die notorischen 9 Steinzeit-Bits) und - noch eine oder zwei weitere User-Passwort-Dateien mit allen administrativen Aufwänden und Sicherheitsrisiken (so als ob's keine Windows-/Domain-Benutzerkonten gäbe). Dies Alles kommt mit cvsNT in Ordnung: Man benutzt einfach die Windows- (Domänen-) Nutzer- und Gruppenkonten ("single sign on") und man kann sehr einfach den Zugriff feingranular mit Dateirechten (ACLs) steuern. Da cvsNT auch einen den "hooks" von Subversion (SVN) vergleichbaren (bzw. komfortableren) Mechanismus bietet, entfallen mit cvsNT eigentlich auch manche Gründe, von CVS auf SVN umzusteigen -- zumal SVN als typisches Linux-Kind mit seinen Windows-Versionen sehr lange Zeit nicht wirklich Freude machte. Mit CollabNet-SVN als Sever und Client (auch für Eclipse) und mit Tortoise-SVN als zusätzlicher Windows-Client lebt man unter Windows inzwischen sehr gut mit SVN (und damit dem main stream). Der prinzipielle große Mangel von SVN, keine Dateiversionen zu führen, ist allerdings auch bei den genannten guten Implementierungen natürlich leider auch noch da ebenso wie der Bug, beim ersten commit (=add) die Dateidaten zu vergessen. Siehe auch [subversion-install-tipp.txt] und [svn-win-de.pdf] im selben Verzeichnis. Also die Empfehlung in einer Windows-Umgebung: Wenn schon CVS, dann aber cvsNT nehmen. Voraussetzungen: a.) Sie haben die Installationsdatei 22.11.2005 18:38 4.003.328 cvsnt-2.5.03.2151.msi (Quelle: http://www.march-hare.com/cvsnt/) oder eine jüngere Version. b.) Sie haben einen geeigneten Server, vorzugsweise mit Windows Server 2003 und RAID (in den folgenden Beispielen PD321S). c.) Dieser Server ist in Ihrem Netzwerk für alle Ihre Client-Rechner zugänglich und hat genügend Plattenplatz für die vorhandenen und mittelfristig absehbaren Projekte Ihrer Nutzer. d.) Dieser Server ist Mitglied der Domäne, in der auch die Konten der CVS-Nutzer geführt werden. e.) Sie haben administrativen Zugriff auf diesen CVS-Server; es genügt remote-Zugriff. f.) Für die Grundinstallation von cvsNT-Client auf den Clientrechnern (Setzen von Systemumgebungsvariablen etc.) benötigt man dort i.A. auch administrativen Zugriff. g.) Einige der im Folgenden gezeigten Tipps, Vereinfachungen und Dateiverbesserungen setzen die Installation eines Java-JDK >= 5 und des Frameworks Frame4J voraus (siehe auch http://www.a_weinert.de/frame4j/). 2. Server - Installation ~~~~~~~~~~~~~~~~~~~~~~ Lassen Sie cvsnt-2.5.03.2151.msi auf dem Ziel-Server laufen. Stimmen Sie den Lizenzbedingungen zu und akzeptieren / setzen Sie C:\util\CVSNT als Zielverzeichnis der Installation. Lassen Sie Server, Client und Lock-Server installieren. Legen Sie (in der Domäne) einen Nutzer cvsAdmin an. Erzeugen Sie auch eine Nutzergruppe CVSUsers und machen Sie sich, cvsAdmin und andere potentielle CVS-Hauptbenutzer zu deren Mitgliedern. Dies geschieht am einfachsten durch einen am einem der Domain-Controller (auch remote) eingeloggten Domain- Administrator. (Falls Domain- und CVS-Administratorrollen, wie oft, in Personalunion vereint sind, vereinfacht sich die Organisation etwas.) Legen Sie (nun wieder am CVS-Server) ein Verzeichnis D:\cvs an. Die hier genutzten Verzeichnis- und andere Namen halten sich an ein konkretes Beispiel und können von Ihnen somit sinngemäß geändert werden, teilweise stellen sie aber auch dringende Empfehlungen der cvsNT-Autoren und -Gurus dar. Geben Sie sich selbst (als CVS-Administrator), den (Domänen-) Administratoren, dem Konto cvsAdmin, der Gruppe CVSUsers sowie dem Konto SYSTEM Vollzugriff auf dieses Verzeichnis; beseitigen Sie dabei ererbte Rechte. Legen Sie zwei Unterverzeichnisse D:\cvs\repo und D:\cvs\tempCVS an. Beseitigen Sie die Nutzer-Umgebungsvariablen TEMP und TMP. Lassen Sie die gleichnamigen System-Umgebungsvariablen auf das selbe (eines !) feste Verzeichnis (zum Beispiel entweder D:\temp oder C:\temp oder ..) zeigen. Mindestens die oben genannten Nutzer (und SYSTEM!) müssen darauf Vollzugriff haben. Legen Sie die System-Umgebungsvariablen CVSROOT=D:\cvs\repo HOME=D:\cvs an. Starten Sie Startmenu -> Programme -> CVSNT -> CVSNT Control Panel und setzen Sie D:\cvs\tempCVS als das "private" Temp-Verzeichnis des CVS-Servers und setzen Sie ferner D:\cvs\repo unter dem Namen cvs/repo als das eine CVS-Repository und stimmen Sie dessen Initialisierung zu. Ein einziges Repository genügt (obgleich mehrere erlaubt sind). Sinnvollerweise setzt man die nächsttiefere Verzeichnisebene als sogenannte "Modul-" Ebene, sprich Projekt-Ebene, ein. Für Projekte einzelner (Domain-) Nutzer oder Nutzergruppen können Sie auf dieser Ebene einfachkeitshalber Verzeichnisse (Module) unter deren Namen (weinert, seidel etc. z.B.) anlegen. Diese Nutzer und Gruppen können (nachdem Sie die entsprechenden ACL-Einträge für diese Projektverzeichnisse gesetzt haben) eine Ebene tiefer ihre Einzelprojekte mit cvsNT selbst anlegen. Fügen Sie mit cvs passwd -a -D FB3-MEVA weinert cvs passwd -a -D FB3-MEVA seidel etc. pp. alle Benutzer hinzu, die den CVS-Server nutzen dürfen. Im Beispiel ist fb3-MEVA der Domänenname, und weinert und seidel sind Nutzerkonten in dieser Domain. Die Zugriffrechte solcher (Domain-) CVS-Nutzer regeln Sie einfach mit den Dateirechten der oben genannten Modulverzeichnisse. Im einfachsten Falle eines (für ein teamfähiges Version Control Systems eher seltenen) Einzelbenutzerprojekts für weinert (beispielsweise) geben Sie weinert, cvsAdmin und SYSTEM Vollzugriff auf D:\cvs\repo\weinert (im Beispiel) und Niemandem sonst dort irgendwelche Rechte -- auch keine ererbten. Sollen weitere Nutzer Lese- und oder Schreibzugriffe auf dieses Projekt bekommen (Lesezugriff für Müller), ergänzen Sie einfach die Dateirechte (ACLs) entsprechend. Stoppen und starten Sie den CVS-Server. (Stoppen Sie den Lock-Server nie; er geht scheint's nur mit re-boot wieder an.) Nach der Installation sieht die Pfadvariable auf dem Server etwa so aus: Path=C:\bat;C:\Programme\util;C:\programme\jdk\bin;C:\WINDOWS\system32; C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\CVSNT\ (Sie könnten überlegen, ob Sie CVSNT etwas nach vorn rücken.) Damit ist die Server-Installation weitgehend erledigt. Es folgt nun noch eine kleine -- aber wichtige -- Server-Nacharbeit, die Sie aber am besten im Anschluss an die erste erfolgreiche cvsNT-Client-Installation von diesem ersten Client aus erledigen. Diese Schritte sind demgemäß am Ende des nächsten Kapitels aufgeführt. 3. Client - Installation -- und Server - Nacharbeit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Auch auf Ihrem -- und auf jedem anderen -- Clientrechner beseitigen Sie die Nutzer-Umgebungsvariablen TEMP und TMP. Lassen Sie die gleichnamigen System- Umgebungsvariablen auf das selbe (eines !) feste Verzeichnis (zum Beispiel D:\temp zeigen. Mindestens die CVS-Nutzer, alle berechtigten lokalen Nutzer dieses Rechners, die Administratoren und das Konto SYSTEM (!) müssen darauf Vollzugriff haben. Hinweis: Falls Sie Bedenken, wegen "Informationsverschleppung" durch dieses gemeinsame TEMP-Verzeichnis haben, halten Sie a) Ihre Nutzer an, eigene temporäre Dateien in jeweils selbstgewählten und konfigurierten temp-Verzeichnissen zu halten und /oder b) räumen Sie das gemeinsame TEMP-Verzeichnis z.B. über logon-Scripts regelmäßig auf. Im Falle b) müssen die manche Nutzer halt lernen, dass "temp" temporär heißt und kein Backup-Archiv ist. Legen Sie die System-Umgebungsvariable cvsroot=:sspi:PD321S:/cvs/repo an. Servernamen und den Namen des Repository's (hier Beispiele) setzen Sie -- wie gesagt -- entsprechend Ihrer obigen Serverinstallation. Auf einem (ordentlich eingerichteten) Client-Rechner sieht die Pfadvariable etwa so aus: Path=C:\bat;C:\;C:\Programme\util;C:\programme\jdk\bin; C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem Installieren Sie mit der bekannten Installationsdatei cvsnt-2.5.03.2151.msi cvsNT (ähnlich wie unter Server beschrieben) auf dem Client-Rechner. Wählen Sie aber nur Client (nicht Server und nicht Lock-Server) aus. Standardmäßig erfolgt die Installation (wie im Server) auf C:\Programme\CVSNT und der Installierer ergänzt dies Verzeichnis hinten an der PATH-Variable. Es ist i.A. günstig alle diese installierten Dateien in ein im "Path" relativ weit vorn stehendes Verzeichnis zu kopieren. Im obigen Beispiel (MEVA-Lab-Standard-Installation) wäre dies am besten C:\util\ Danach können Sie obiges Installationsverzeichnis löschen und den PATH wieder kürzen bzw. eine zusätzlich angelegte, verlängerte Benutzer-PATH-Variable löschen. Das Verzeichnis C:\Programme\util wird durch diesen Vorgang i.A. um folgende Dateien ergänzt: 14.11.2005 18:36 761.856 cvs.exe 14.11.2005 18:37 341.449 cvs.chm 14.11.2005 18:36 396.800 cvsapi.dll 14.11.2005 18:36 151.552 cvstools.dll 14.11.2005 18:36 9.216 enum_protocol.dl 14.11.2005 18:36 114.688 expat.dll 14.11.2005 18:36 9.728 ext_protocol.dll 14.11.2005 18:36 6.144 ext_xdiff.dll 14.09.2004 11:32 888.832 iconv.dll 14.11.2005 18:36 16.384 mdnsclient.dll 14.11.2005 18:36 11.264 ssh_protocol.dll 19.03.2004 22:37 155.648 ssleay32_vc71.dl 14.11.2005 18:36 25.600 sspi_protocol.dl Diese könnten Sie sich auch von der Serverinstallation oder besser von einer (gelungenen) Client-Installation holen und einfach direkt (ohne Installer) auf alle (softwaremäßig ähnlichen) Client-Rechner verbreiten. Die aufgeführte Auswahl an Dateien genügt für den :sspi:-Zugriff von einer Windows 2003- Client-Workstation; bei älteren Versionen (Windows 2000) benötigt man evtl. noch eine neuere (und größere) Version von 24.03.2005 18:38 665.600 C:\WINDOWS\system32\dbghelp.dll Achten Sie bei jeder (!) Installation darauf, dass keine ältere Version von cvs.exe (mit Linux-Herkunft und -Gewohnheiten) irgendwo rumspukt -- dann klappt nämlich gar nichts. Im Erfolgsfalle muss X:irgendwo> cvs --version dies Concurrent Versions System (CVSNT) 2.5.03 (Scorpio) Build 2151 (client/server) ...... oder eine ähnliche Ausgabe mit einer höheren Version, sowohl auf dem Client als auch auf dem Server, liefern. Damit ist auch die jeweilige Client-Installation abgeschlossen. Vom allerersten so installierten Client aus erledigen Sie, am besten sofort, die letzten wichtigen administrativen Server-Einstellungen. Diese können dort mit cvsNT-Mitteln vorgenommen werden. Dies so zu tun, ist somit auch gleich "Übung und Test" für die cvsNT-Client-Server-Kommunikation. Also dann ... Server-Nacharbeit: Geben Sie folgender Kommandofolge auf einer Kommando-Shell des Clients ein: X:\x\z\irgendwo>cd /d D:\temp D:\temp>md 21s D:\temp>cd 21s D:\temp\21s>cvs co CVSROOT D:\temp\21s>cd CVSROOT D:\temp\21s\CVSROOT>editpad cvswrappers Nun mit Editpad diese Textdatei gemäß Anhang A) ändern und speichern. D:\temp\21s\CVSROOT>cvs commit -m "Typen für Binärdateien" D:\temp\21s\CVSROOT>cd ..\.. D:\temp>java Del -empty 21s\CVSROOT\ Bei korrekter Installation auf Server und Client muss dies problemlos durchlaufen. Geschehen ist im dabei Einzelnen folgendes: 1) Anlegen eines temporären Arbeitsverzeichnisses, gelegentlich "Sandbox" oder "(local) working directory" genannt. 2) Aus-Checken der Konfigurationsdateien des CVS-Servers; CVSROOT funktioniert bei cvsNT wie eine normales CVS-Modul (=Projekt). 3) Ändern der Datei cvswrappers gemäß Anhang A. 4) "Committen" der Änderung, also hier nur der geänderten Datei cvswrappers. 5) Die angelegten lokalen Dateien und Verzeichnisse auf dem Client können gelöscht werden. Sie sind vom CVS-Server jederzeit wieder abholbar. Hinweis: Punkt 5) bzw. die ganze Folge weist auch gleich auf eine notwendige Änderung der Arbeitsgewohnheiten bei der Umstellung auf ein serverbasiertes Versionskontrollsystem hin: Man halte niemals lokale Kopien, mit denen man weiter und immer weiter arbeitet; die Abfolge ist stets raus -> ändern -> zurück. Zum Hintergrund diese nur einmal vorzunehmenden sehr wichtigen (!) Schrittes siehe Anhang A unten. 4. Übernahme eines (alten) CVS-Projekts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ein bereits vorhandenes CVS-Repository, auch ein bisher mit einer anderen älteren CVS-Version (Linux-like) verwaltetes, kann einfach als weiteres Modul (=Unterverzeichnis) in das Repository, sprich nach D:\cvs\repo auf den cvsNT-Server kopiert werden. Kontrollieren bzw. setzen Sie dann in D:\cvs\repo\altesCVSzeugsDorthinKopiert die Dateirechte, d.h Sie geben mindestens dem (Haupt-) Nutzer dieses Projekts, cvsAdmin und SYSTEM Vollzugriff. (Und zusätzliche Rechte für weitere Benutzer dieses Projekts setzen Sie entsprechend.) Hinweis zum Setzen von Dateirechten: Neben dem üblichen wohlbekannten graphischen Zugriff via Explorer -> Datei/Verzeichnis -> Eigenschaften -> Sicherheit setzt man hier für die professionelle Verwaltung von Datei-ACLs eher Kommandozeilentools wie cacls, setacl oder roboCopy (Kopieren mit ACLs-Mitnahme) ein. 5. Einrichten eines (neuen) Projekts bzw. Moduls ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Das Anlegen eines neuen Projekts oder Moduls ist ein wichtiger Vorgang. Da er i.A. als erstes nach einer cvs- bzw. cvsNT-Installation auszuführen ist, könnte man in sogar "fundamental" nennen. Umso unverständlicher und mehr als lästig ist es, dass dieser Vorgang von cvs und leider auch cvsNT schwach, ja eher gar nicht, unterstützt wird. Hinzu kommt, dass die Tipps und Rezepte, auch die in der Original-Dokumentation, weitestgehend irreführend sind. Die Hauptprobleme (mit import) sind: - Ein (naheliegender) import einer vorliegenden mit Dateien besiedelten Verzeichnisstruktur erzeugt gerne einen (selten und hier schon gar nicht gewünschten) Branch mit scheußlichen und schwer zu beseitigenden vierstelligen Revisionsnummern. - Ein import einer leeren Verzeichnisstruktur (ein "heißer" Tip, auf dessen Plausibilität wohl jeder einmal reinfällt) funktioniert einfach nicht, da cvs und cvsNT hartnäckig unwillig (unfähig?) sind, leere Unterverzeichnisse zu importieren. Das im folgenden beschriebene Vorgehen macht diesen Fehler, trotz ersten Anscheins, nicht. - Und Reparaturtipps mit leeren dummy-Dateien in den Blättern der leeren Verzeichnisstruktur nimmt man bitte nicht ernst: Man verdirbt ein unter Versionsverwaltung stehendes Projekt nicht gleich am Anfang mit dort nicht hingehörenden Dateien. N.B.: In einem Versionsverwaltungssystem werden Dateien nie wirklich gelöscht. Eine solche Anfangssünde kann also noch nach Jahren für Verwirrung sorgen. Anmerkung / Hinweis: In cvsNT können Sie auf dem Server / im Repository auch Dateien löschen (mit Angstschweiß und falls alles Andere versagt). Deren "historische Information" ist dann i.A. auch endgültig weg. Man muss da dann wirklich wissen, was man tut. Ein bewährter Weg zum Anlegen eines neuen Projekts oder Moduls (mit Beschränkung auf das Kommandozeilen-Tool) ist: 1) Anlegen des Projekts als neue leere (!) (Sandbox-) Verzeichnisstruktur auf einem Client mit sinngemäß der folgenden entsprechenden Kommandofolge >md site\meva-lab\java\docs\aWeinertBib >md site\meva-lab\docu >md site\meva-lab\images >md site\meva-lab\lehre >md site\aktuelles >md site\it-automation Zur Kontrolle des gewünschten Ergebnisses kann man tree verwenden: >tree site +---aktuelles +---it-automation \---meva-lab +---docu +---images +---java | \---docs | \---aWeinertBib \---lehre Wichtig: Daher nochmal der Hinweis, dass "leer" hier keine einzige Datei bedeutet. 2) Wechseln in das Wurzelverzeichnis des neuen Projekts >cd site 3) Importieren des leeren Verzeichnisses xy\site>cvs import -m "Struktur site leer" site weinert start No conflicts created by this import Dies "importiert" nur das Grundverzeichnis (!), da leere Verzeichnisse hartnäckig ignoriert werden (s.o.). An dieser Stelle kann (und sollte) man die Dateirechte des neuen Projektgrundverzeichnisses (hier site) auf dem cvsNT-Server setzen. Hinweis: site im obigen Beispiel ist das "repository", also das Verzeichnis bezogen auf die cvs-Wurzel im cvs-Server. weinert und start sind "vendortag" und "releasetag". Ersetzen Sie ersteres durch eine für Ihren Fall passende Bezeichnung und lassen Sie das übliche start. 4) Auschecken des (noch leeren) Repository's in das "Sandbox"-Verzeichnis xy\site>cd .. >cvs co site cvs server: Updating site Dies macht aus der "Sandbox" ein "echtes" lokales Arbeitsverzeichnis. Wieder dorthin wechseln mit >cd site 5) Besiedeln mit möglicherweise bereits vorhandenen Dateien Nun erst (nicht vorher!) wird die Verzeichnisstruktur mit den dorthin gehörenden Dateien besiedelt. Auch (im Schritt 1 vergessene) Verzeichnisse sollten jetzt erzeugt werden. xxyxx\publication\cvsnt-tipp.txt \ ... etc. pp 6) Hineintragen der Dateien und Verzeichnisse in das Repository Bis jetzt kennt das Repository (auf dem Server) nur das leere Projektgrundverzeichnis (site im Beispiel). Man muss nun alle Dateien und Unterverzeichnisse einzeln (mit add) dort hintragen und dabei alle nicht leeren Unterverzeichnisse rekursiv besuchen. xy\site>cvs add file1 \ ::: \ xy\site>cvs add aktuelles > so besser nicht xy\site>cd aktuelles / xy\site\aktuelles>cvs add file21 / ::: Dies beginnt bei mehr als fünf Dateien oder Verzeichnissen lästig und fehlerträchtig zu werden. (Und spätestens jetzt fragt man sich, wer einen import-Befehl erfunden hat, der genau diese benötigte und erwartete Funktion nicht bietet.) Deswegen vereinfacht man sich das Ganze mit dem Skript cvsAddAll.bat aus Anhang C zu: xy\site>cvsAddAll Hatte man nur eine leere Verzeichnisstruktur (sprich eine ohne Dateien), so ist die Sache hiermit auf Client und Server erledigt. Falls man für Unterverzeichnisse (z.B. aktuelles im obigen Beispiel) unterschiedliche Zugriffsrechte benötigt, ist jetzt der Zeitpunkt, diese auf dem Server zu setzen. 7) Und schließlich .. War die mit xy\site>cvsAddAll in den Server getragene Verzeichnisstruktur nicht leer, war also wenigstens eine (neue) Datei dabei, ist ein anschließendes commit fällig xy\site>cvs commit -m "Erstbesidelung" 8) optional -- aber nur bei Erfolg Löschen der "Sandbox" auf dem Client-Rechner Den Erfolg prüft man durch ein Checkout in eine vollständig leeres (Temp-) Verzeichnis >cd /D D:\temp D:\temp>md 21s D:\temp>cd 21s D:\temp\21s>cvs co site Wenn dort alles ankommt, kann mann alle lokalen Kopien (auch D:\temp\21s\site\...) löschen. Was ist im Einzelnen passiert? Die beispielhaften Schritte 1) bis 3) legen ein Projektverzeichnis (hier im Beispiel site) auf dem cvsNT-Server an. Man kann so sinngemäß auch Unterprojekte, wie z.B. weinert/publication auf dem cvsNT-Server anlegen. Nach diesem Anlegen der Projekt- bzw. Modul- oder auch Untermodulverzeichnisse sollte man, wie erwähnt, deren Dateirechte (ACLs) auf dem Server kontrollieren bzw. korrigieren. Man kann übrigens vor dem obigen allerersten Import auch ein solches (Modul-) Verzeichnis auf dem Server mit passenden Rechten (s.o.) leer anlegen. Die Befehle von Schritt 4) machen aus dem "Sandbox"-Verzeichnis im Client- Rechner ein lokales CVS- "working directory". Schritte 5) und 6) besiedeln dieses mit bereits vorhandenen Dateien und fügen diese (add) dem CVS-Repository lokal zu. Dies lässt sich mit Skripten (siehe Anhang C) leicht automatisieren, da mehrfaches "add" absolut unschädlich ist. Schritt 7) tut das Ganze dann in das CVS-Repository auf dem Server. Ist man bei den vorigen Schritten in Unterverzeichnisse "abgetaucht", muss man vorher wieder ins (Sandbox-) Grundverzeichnis (site) wechseln. Bei ungetrübten Lauf macht das Skript von Anhang C das alleine. (Dennoch kontrollieren.) Hinweis 1: cvsNT akzeptiert (als Windows-tool) freundlicherweise auch Gegenschrägstriche bei Projekt- / Modulbezeichnungen. Die beiden Befehle D:\temp\21s>cvs co weinert\publication D:\temp\21s>cvs co weinert/publication funktionieren also gleich. Dies ist besonders für Skripte (batch-Dateien) nützlich, wo man so (endlich und ohne Bastelei) den selben Parameter als Modulbezeichung und als Teil eines Verzeichnisnamens nutzen kann. Hinweis 2, Nochmals zur Erinnerung bzw. Warnung: Anstelle der nur auf den ersten Blick komplexen und leicht automatisierbaren o.g. 8 Schritte kann man auch eine mit Dateien gefüllte Directory-Struktur in einem Zug importieren (statt erst leer und dann add, add, add, ..). Diese kleine Bequemlichkeit erzeugt allerdings statt schöner 1.1-Revisionen hässliches "1.1.1.1", über das man sich dann noch lange ärgert. Siehe Anfang des Kapitels. Hinweis 3, Rekapitulation: Ein weiteres Sub-Repository "tomkater" unter "site" (im obigen Beispiel) erzeugt und besiedelt man dann später so: md make md make\site md make\site\tomkater md make\site\tomkater\pd321s cd site cvs import -m "TomCats Projekt" site\tomKater weinert start cd .. cvs co site/tomKater cd site\tomkater md pd3021 md pd3021\Catalina xcopy ...... /* erst jetzt mit "echten" Dateien besiedeln cvsaddall cvs commit -m "Erste Besiedelung" 6. Sichern der Projekte ~~~~~~~~~~~~~~~~~~~~ Auf einem Backup-Server (PD3082 im Beispiel) legt man ein freigebebenes Verzeichnis \\Pd3082\CVS21Sback mit Unterverzeichnissen A und B (für tagesweise abwechselnde Sicherung) an. Hierauf bekommen Domain-Administratoren, SYSTEM und cvsAdmin Vollzugriff. Auf dem cvsNT-Server (PD321S in den Beispielen) stellt man das im Anhang C aufgeführte Skript roboLocCVSto82.bat (oder eine sinngemäße Abwandlung) bereit. Auch auf dem Server richtet man eine täglich um 03:39 (beispielsweise) unter dem Nutzerkonto cvsAdmin (! wichtig) laufende Task ein. Dies sorgt nun dafür, dass immer eine gestrige und vorgestrige Sicherung des Repository's verfügbar angelegt wird. Die Verwendung von roboCopy ist entscheidend, da nur so die feingranularen und wesentlichen Dateirechte (ACLs) mit gesichert werden. Vor dem Anlegen der Task testet man den ganzen Sicherungsvorgang und die Skriptdatei mit runas /user:cvsAdmin@FB3-MEVA.fh-bochum.de C:\bat\roboLocCVSto82.bat 7. Zum Export ~~~~~~~~~~ Checkout und Commit ist der normale Arbeitszyklus, welcher bei Text-Dateien (nicht Binär-Dateien; vgl. Anhang A) zur "keyword-Ergänzung" führt. Aus --- Version V§Revision§ Zuletzt geändert von §Author§ am §Date§ --- wird nach dem ersten Commit etwas wie --- Version V§Revision: 1.1 § Zuletzt geändert von §Author: FB3_MEVA\weinert § am §Date: 2005/12/06 15:00:45 § --- Hinweis: Lesen Sie hier bitte $ (Dollar) statt § (Paragraph). Würde bei diesen Beispielen hier $ stehen, müsste der Autor was Besonderes tun, damit Alles so bleibt, da auch dieses vorliegende Dokument mit cvsNT verwaltet wird. Export (mit -kv) statt Checkout beseitigt die Schlüsselworte endgültig: --- Version V1.2 Zuletzt geändert von FB3_MEVA\weinert am 2005/12/06 15:00:45 --- Dies ist ja dann die Form die man zum Ausliefern, Bauen, Drucken, für JavaDoc und dergleichen verwendet. Allerdings nicht wirklich: Neben einigem Anderen stört auch auch der Domänename statt des Menschennamens und das verkorkste Datumsformat. Dies Alles wird schöner, wenn man die "keyword-substitution" bzw. das "keyword-stripping" nicht mit Export + Option -kv sondern mit dem (Java-) Werkzeug de.frame4j.SVNkeys erledigt. Obiges Ergebnis verbessert sich dann zu --- Version V1.2 Zuletzt geändert von A. Weinert am Mi, 07.12.2005, 15:19 --- Eine beispielhafte Kommandofolge zum Export mit einem solchen Ergebnis entnimmt man bitte Anhang B. Also nochmals der Hinweis (gilt auch für cvs): Besser nie -export verwenden sondern stattdessen -checkout und danach de.frame4j.SVNkeys . 8. Rename -- Fallen ~~~~~~~~~~~~~~~~~~ Ein weiterer Vorzug von cvsNT gegenüber dem Ur-CVS und Ähnlichem soll ja sein, dass es Verzeichnisse kennt und Dateien verschieben und umbenennen kann. So wird es jedenfalls behauptet. Bei Letzterem ist aber leider mehr als Vorsicht geboten. Der Versuch, mit cvs rename people.html it-a.html einer Datei eines Internetauftritts einen neuen Namen (unter Beibehaltung der aktuellen Revision 1.13 oder halt auch 1.14 wegen des Umbenennens) zu geben, führt zu einer wohl lieb gemeinten Warnung. Die Warnung besagt, dieses Kommando sei "highly experimental" und mag evtl. nicht wie erwartet funktionieren. Achtung / Falle: Wenn Sie diese Warnung lesen, ist die Katastrophe schon eingefädelt. Nach einer kleinen Änderung an der (auch lokal) umbenannten Datei, also im Beispiel nun an it-a.html, ahnt man die Katastrophe spätestens, wenn bei commit irgendwas wie "people.html as it-a.html" gemeldet wird. Anschließendes checkout liefert nun häufig den neuem Inhalt mit höherer Revision unter dem alten Namen. Wohlgemerkt: geändert wurde an der umbenannten Datei. Verzweifelte Versuche, nun nachträglich doch brav mit add, delete, rückwärts-rename und sonst was einen konsistent funktionierenden Zustand zu erreichen, schlagen fehl. Letztlich half nur (hier stark vereinfacht): remove beider Dateien (people.html und it-a.html) commit Beseitigen der Datei people.html,v auf dem cvsNT-Server (!) add der Datei it-a.html commit Der, wie Experimente zeigten, leider unumgängliche dritte Schritt (denn diese Datei scheint nun irgendwie beide Namen zu personifizieren und das aber willkürlich falsch), macht die Katastrophe nun natürlich komplett. Ab da funktioniert zwar wieder Alles -- fast. "Fast alles" meint erstens und vor Allem: Nun ist die Vergangenheit der betreffenden Datei kaputt oder nötigenfalls nur über Sicherungsdateien wieder herstellbar. Nota bene: wir wollten sie ja nur umbenennen! Im konkreten (Beispiel-) Projekt war das egal, da wir für Web-Auftritte extrem selten in der Vergangenheit forschen mussten. Aber eigentlich wäre jetzt ein Neuaufsetzen des Repository's aus der letzten Sicherungskopie mit wahrscheinlichem Verlust einiger Tagesarbeit angesagt gewesen. Die fehlende Funktion: "set / increment by revision" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mit dem neben der nun fehlenden Vergangenheit "fast alles" ist zweitens gemeint, dass die nun ja doch mit remove und add umbenannte Datei (it-a.html im Beispiel) jetzt die Revision 1.1 statt 1.15 hat. Dies scheint sich nun auch durch nichts reparieren zu lassen -- vorausgesetzt mal man zieht (hier) 14 "committete" dummy-Änderungen nicht ernsthaft in Erwägung. Wer den teilweise zu findenden Versprechungen "commit ... -r .." vertraut, wird enttäuscht. Hier versagt cvsNT ebenso wie das Ur-CVS. Diese einfache und vielfach dringend benötigte Funktion, nämlich das Erhöhen von Datei- Revisionen, scheint schlicht zu fehlen. Hinweise sind willkommen. (Hinweise auf die Funktion wohlgemerkt, keine praxisfernen "Beweise", dass man so was nicht brauchen darf. Der SVN-Fan versteht die Aufregung nämlich nicht, da SVN keine Datei- Versionen hat, und man das als Fan gut findet.) Also: Mit rename people.html it-a.html cvs remove people.html cvs add it-a.html commit .... sprich (ohne das Unglück mit cvs rename) stünde man nun deutlich besser da. Und die ungewünschte falsche Datei-Revision haben wir nun ja auch. Kurzzusammenfassung: Hände weg von cvs rename! 9. Anhang ~~~~~~ Anhang A: CVS Wrapper (für Windows) ~~~~~~~~~~~~~~~~~~~~~~~~~ CVS muss (im Gegensatz zu SVN) wissen, welche Dateitypen Binärdateien sind. Dies geschieht mit der Text- (Konfigurations-) Datei CVSROOT/cvswrappers. So als solche bekannt gemachte Binärdateien werden von CVS in ihrer jeweiligen Version bitgenau, also u.a. ohne "keyword-substitution" oder plattformabhängige Zeilenvorschub-Bastelei geliefert. Ein Beispiel für cvsWrapper: --------------- # This file affects handling of files based on their names. # The -m option specifies whether CVS attempts to merge files. # The -k option specifies keyword expansion (e.g. -kb for binary). # The -t option overrides the default mime type. # # Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers) # # wildcard [option value] [option value]... # # where option is one of # -k expansion mode value: b, o, kkv, etc. # # and value is a single-quote delimited value. # For example: *.gif -k 'b' # 06.12.2005 07:26 A.W. : weitere Endungen (Staroffice, Openoffice) # $Revision" (Do, 12.10.2006, 09:30) A. Weinert *.ser -k 'b' *.avi -k 'b' *.cab -k 'b' *.class -k 'b' *.doc -k 'b' *.dll -k 'b' *.exe -k 'b' *.exp -k 'b' *.gif -k 'b' *.gz -k 'b' *.jar -k 'b' *.war -k 'b' *.jpg -k 'b' *.jpeg -k 'b' *.lib -k 'b' *.msi -k 'b' *.mso -k 'b' *.pfw -k 'b' *.png -k 'b' *.ppt -k 'b' *.sit -k 'b' *.tar -k 'b' *.tlb -k 'b' *.vsd -k 'b' *.xls -k 'b' *.wmz -k 'b' *.zip -k 'b' *.tif -k 'b' *.tiff -k 'b' *.xls -k 'b' *.sxw -k 'b' *.odt -k 'b' *.ott -k 'b' *.oom -k 'b' *.oth -k 'b' *.oos -k 'b' *.ots -k 'b' *.ood -k 'b' *.otd -k 'b' *.oop -k 'b' *.otp -k 'b' *.odb -k 'b' *.oof -k 'b' *.stw -k 'b' *.sxg -k 'b' *.sxc -k 'b' *.sxi -k 'b' *.sti -k 'b' *.std -k 'b' *.sxm -k 'b' *.pdf -k 'b' *.rdp -k 'b' *.wmf -k 'b' *.bmp -k 'b' *.ico -k 'b' *.so -k 'b' *.dot -k 'b' *.xlw -k 'b' *.pot -k 'b' -------------- Kommen in Ihren Projekten weitere Binärdateitypen (CAD-Zeichnungen z.B.) vor, müssen Sie sinngemäß weitere Zeilen ergänzen. Binärdateien, die, wie beispielsweise *.obj oder *.lnk, das Ergebnis von (C- und ASM-) Übersetzungen und damit Zwischenergebnisse eines build-Prozesses sind, könnten mit aufgenommen werden. Wenn solche Zwischenergebnisse eindeutiges Ergebnis versionierter Quelldateien sind, nimmt man solche Dateien i.A. sinnvoller- und üblicherweise gar nicht mit unter Versionskontrolle (und muss sie dann auch nicht cvswrapper aufführen). Solche "Ergebnis-" Dateien erzeugt man am Besten im Rahmen eines Auslieferungsvorgangs (deployment) mit dem zugehörigen Skript (batch-Datei) oder fügt sie, falls vorher anderweitig bereitgestellt, mit diesem Skript dem Auslieferungspaket zu. Tipp: Ein solches "deployment-" Skript kann sich dazu vorteilhaft kleiner ANT-Hilfstasks bedienen; Beispielauszug: :::: usw. ---- Anhang B: "Schöne" keyword-substitution ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Die folgende beispielhafte Batch-Datei bekommt zwei oder drei Parameter. Es sind : Parameter 1 (%1): das Modul (z.B. weinert/publication) Parameter 2 (%2): das Zielverzeichnis (z.B. D:\weinert\publication) und optional Parameter 3 (%3): der Tag-Name der zu holenden Revisionen (ohne Angabe = das neuste) Hinweis : Der "Tag-" Name ist der gemeinsame Versionsname eines Satzes von Datei-Revisionen. Dieser Satz von Dateien sollte zusammengehörig und in sich konsistent sein (ein Auslieferungszustand z.B.). ------------ @Echo cvsExport.bat V01.02 11.12.2005 if %2X==X goto :ende @set CVSEXKrit=-r HEAD @if NOT %3X==X set CVSEXKrit=-r %3 @Echo Export %1 to %2\%1; criteria %CVSEXKrit% @cd /d D:\temp @Echo leeres Verzeichnis D:\temp\CVStemp\ bereitstellen java Del -empty \temp\CVStemp\ md \temp\CVStemp cd \temp\CVStemp\ @Echo. @Echo Export mit Kriterium %CVSEXKrit% @Echo. cvs export %CVSEXKrit% -d . %1 @if errorlevel 1 goto :cvsfail @echo SVNkeys . @REM oder auch etwas wie java SVNkeys . -omitDirs CVS;doc-files java SVNkeys . @if errorlevel 1 goto :cvsfail cd /D %2 @Echo Overwriting with exported files XCopy /S /Y D:\temp\CVStemp\*.* .\ @REM XCopy /S .. nimmt versteckte Verzeichnisse (CVS) i.A. nicht mit goto :ende :cvsfail @echo CVS failed :ende -------------- Anhang C: Back-Up-Skript ~~~~~~~~~~~~~~ -------------- @Echo roboLocCVSto82.bat 13.12.2005 10:00, A. Weinert @Echo. @Echo robocopy-Sicherung des lokalen cvsNT-Ropsitory's nach PD3082...A / B @Echo. @title Sicherung des lokalen cvsNT-Ropsitory's net stop cvsnt @if exist D:\temp\adran.txt ( robocopy D:\cvs\ \\Pd3082\CVS21Sback\A\ /S /E /SEC /A-:RASH /R:4 /W:6 del D:\temp\adran.txt ) ELSE ( robocopy D:\cvs\ \\Pd3082\CVS21Sback\B\ /S /E /SEC /A-:RASH /R:4 /W:6 echo %date% > D:\temp\adran.txt ) net start cvsnt -------------- Anhang D: Add-All-Skript ~~~~~~~~~~~~~~ -------------- @Echo. @Echo off @Echo cvsAddAll.bat V0.01, 28.12.2005 16:12, A. Weinert (%1) @Echo. @Echo add the Files @for %%i in (*.*) do ( @echo cvs add %%i @cvs add %%i @if ERRORLEVEL 1 @echo ignore %%i has already been entered error @Echo. ) @Echo add the Dirs @for /D %%i in (*.*) do ( @echo cvs add %%i @cvs add %%i @if ERRORLEVEL 1 @echo ignore %%i already there error @Echo. @Echo --- recursion ---- @Echo cd %%i @cd %%i @Call %0 %%i @Echo cd .. @cd .. @Echo. ) --------------