Humboldt-Universität / Computer- und Medienservice / Benutzer-Howto und FAQ für den CVS-Server cvs.cms.hu-berlin.de

Benutzer-Howto und FAQ für den CVS-Server cvs.cms.hu-berlin.de

(CVS: The Concurrent Versions System;   FAQ: Frequently Asked Questions)

(Über unseren URLMinder können Sie veranlassen, per E-Mail benachrichtigt zu werden, wenn diese Seite geändert wird.)

Inhalt:

1 Allgemeines

1.1 Was ist CVS?

Das Akronym CVS steht für "The Concurrent Versions System". Es wird hauptsächlich bei der Software-Entwicklung eingesetzt und ist in der Open-Source-Szene das am weitesten verbreitete Versionskontrollsystem (VCS - Versioning Control System oder auch SCM - Software Configuration Management). Mehr dazu im Abschnitt "Wie unterstützt mich CVS bei der Soft...".

1.2 Wo und wie kann ich einen Zugang zum CVS-Server beantragen?

Anträge nimmt die Webtech-Gruppe (webtech@cms.hu-berlin.de) entgegen.

ALERT! Der CVS-Server steht ausschließlich CMS-Mitarbeitern zur Verfügung. Andere Einrichtungen (Fakultäten, Institute, Lehrstühle ...) können leider nicht den CMS-CVS-Server verwenden und auch nicht beim Aufbau eines eigenen CVS-Servers unterstützt werden, da dafür die Personalkapazitäten fehlen.

Folgende Angaben sind notwendig:

  • Name des Repositories (bzw. Name des Projekts)
  • Liste der Software-Entwickler: Vorname, Nachname und Benutzer-Konto (Mail-Account - nicht die E-Mail-Adresse) am CMS
  • optional können auch die öffentlichen SSH2-Keys der Entwickler (Format egal - IETF oder OpenSSH - Hauptsache SSH2) mit übermittelt werden, um den CVS-Zugang zu vereinfachen

Wichtige Hinweise:

  • Ein Zugang ist nur möglich, wenn die Software-Entwickler einen gültigen und aktiven Account (mit Basisservice) am CMS besitzen (dieser Account wird für den CVS-SSH-Zugang verwendet)
  • Mit der Erteilung des Auftrags, ein neues Repostitory einzurichten, erfolgt auch eine Zustimmung zu den Verhaltensrichtlinien im Umgang mit dem CVS-Server

1.3 Welche Verhaltensrichtlinien gibt es im Umgang mit dem CVS-Server?

  • es sollte nicht unnötig Speicherplatz verschwendet werden
    • möglichst nur Quell-Code und zugehörige Daten einchecken (commiten), d.h. es soll kein Binär-Code, der aus dem eingecheckten Quell-Code erzeugt werden kann, eingecheckt (commitet) werden
    • keine Distributionen (.tar-Archive/.zip-Dateien), die aus dem Repository erzeugt werden können, einchecken

1.4 Welche Betriebssysteme und Entwicklungsumgebungen unterstützen CVS oder werden von CVS unterstützt?

Folgende Betriebssysteme:
  • Allgemein: (fast) alle, u.a:
    • (fast) alle UNIX/Linux-Systeme
    • Windows
    • MacOS (X)

Entwicklungsumgebungen:

1.5 Welche grafischen Frontends gibt es für CVS?

Idealerweise verwendet man Entwicklungsumgebungen, die CVS unterstützen. Aber manchmal hat man Dateien im CVS, die man nicht mit CVS-unterstützende Entwicklungsumgebungen bearbeiten kann. Folgende grafischen Frontends kann man dann u.a. verwenden:

1.6 Wer hat alles Zugang zu den Repositories und zum CVS-Server?

Der Zugriff auf dem CVS-Server ist sehr restriktiv, d.h. das nur explizit eingetragene Benutzer Zugriff auf die CVS-Repositories erhalten und auch nur auf die, für die sie berechtigt sind. Es gibt also keinen anonymen Zugang und auch keine Möglichkeit, ohne explizite Berechtigung auf andere Repositories zuzugreifen.

1.7 Wie (ausfall-)sicher ist der CVS-Server?

Zugriffssicherheit:
  • Der Zugang ist sehr restriktiv und nur über eine Secure-Shell möglich.
  • Ein direktes Einloggen ist für Benutzer jedoch nicht möglich - es darf nur mittels CVS über SSH zugegriffen werden.
  • Es ist kein anonymer Zugriff auf die Repositories möglich und die Filesystem-Rechte verbieten es anderen Entwicklern, auf Repositories zuzugreifen, für die sie nicht eingetragen sind.

Datensicherung:

  • Von dem Server werden einmal täglich Datensicherungen in das TSM (zentrales Backup auf Bandrobotern) durchgeführt.
  • Außerdem wird alle 10 Minuten eine Sicherung (Synchronisation) auf den Ausfall-Server durchgeführt.

Ausfallsicherheit:

  • Alle 10 Minuten wird eine Sicherung (Synchronisation) der Daten und Konfigurationen auf den Ausfall-Server durchgeführt.

  • Es erfolgt derzeit noch keine automatische Umschaltung auf den Ausfall-Server, d.h. es kann unter Umständen einige Zeit dauern, bis der Ausfall-Server den cvs.cms.hu-berlin.de ersetzt (inkl. Übernahme des Namens cvs.cms.hu-berlin.de).

  • Zum Server selbst:
    • Die Festplatten fürs Betriebssystem und die Platten für die CVS-Repositories werden im RAID1 (redundant) betrieben.
    • Der Server besitzt 3 redundante Netzteile, die an drei verschiedenen Sicherungen angeschlossen sind.
    • Der Ausfallserver ist hardwaremäßig identisch mit dem CVS-Server.

1.8 Wieviel Speicherplatz steht für ein CVS-Repository zur Verfügung?

Auf dem CVS-Server stehen derzeit 120GB zur Verfügung. Derzeit ist der Speicherplatz für ein CVS-Repository nicht beschränkt (quotiert). Wenn möglich, sollte der Speicherplatz nicht unnötig verschwendet werden (möglichst nicht mehr als 1-2GB pro Repository verwenden).

1.9 Wie unterstützt mich CVS bei der Software-Entwicklung oder warum sollte ich gerade CVS bei der Software-Entwicklung verwenden?

Gerade wenn mehrere Entwickler an der gleichen Software arbeiten, kommt man um ein Versionskontrollsystem wie CVS nicht herum. Es ist extra dafür entwickelt worden, die Zusammenarbeit in Entwickler-Gruppen an gemeinsamen Software-Projekten zu unterstützen und zu vereinfachen.

CVS (The Concurrent Versions System) wird in fast allen Open-Source-Projekten verwendet. Seit einigen Jahren hat CVS Konkurenz durch das Subversion-Projekt (http://subversion.tigris.org/) bekommen, jedoch ist die CVS-Unterstützung gerade bei Entwicklungsumgebungen immernoch unschlagbar.

Welche Fähigkeiten und Möglichkeiten bietet mir CVS konkret:

  • jede Datei im Repository wird versioniert:
    • jede Änderung am Repository kann rückgängig gemacht werden
    • Vergleiche zwischen den Versionen sind möglich (diff)
    • Änderungsverfolgung: Wer hat wann, was und vielleicht auch warum verändert?

  • parallele Änderungen an der selben Datei sind möglich (bei Änderungs-Kollisionen muss der letzte Entwickler, der commitet, den Code mergen/zusammenführen bevor er selber commiten kann - Kollisionen passieren aber eher selten, im Normalfall wird der Code automatisch zusammengeführt)

  • E-Mail-Benachrichtigung über Änderungen im Repository

  • CVS unterstüzt Branches: bei grundlegenden Änderungen kann ein neuer Entwicklungs-Zweig (Branch) angelegt werden, während der Hauptzweig unabhängig vom neuen Zweig weiterentwickelt werden kann

  • Es können (Release-)Tags gesetzt werden, um einen aktuellen Stand der Software (/ eine Version) jederzeit exportieren bzw. auschecken zu können.

  • ...

1.10 Warum soll ich gerade diesen und nicht einen eigenen CVS-Server verwenden?

Der CVS-Server des CMS:

  • bietet hohe Ausfallsicherheit (redundante Hardware)
  • eine Datensicherung in das zentrale Backup-System des CMS (Bandroboter an verschiedenen Standorten)
  • einen Ausfallserver (extra Server - wer kann sich schon sowas leisten außer dem CMS?)
  • wird von CMS-Mitarbeitern (Webtech-Gruppe) administriert (das CMS nimmt Ihnen den Administrations-Aufwand ab)
  • ...

1.11 Welche Alternativen existieren neben CVS?

Es gibt eine ganze Reihe von Versionskontrollsystemen. Die meisten (kommerziellen) Systeme bezeichnen sich als SCM-Systeme (Software Configuration Management) oder als VCS-Systeme (Versioning Control System).

Kostenlose Versionskontrollsysteme:

Kommerzielle Versionskontrollsysteme (nur die bekanntesten):

Einen Vergleich zwischen diesen und anderen VCS/SCM-Systemen findet man beispielsweise unter: http://better-scm.berlios.de/comparison/comparison.html

2 Benutzung

2.1 Was muß ich unbedingt tun und wissen, bevor ich mit dem CVS-Server arbeite?

2.1.1 CVS installieren, falls noch nicht vorhanden.

Linux/UNIX:
Die meisten Linux-Distributionen bringen Installationspakete für CVS mit. Die Installation selbst ist natürlich abhängig von der Distribution (SuSe: yast2, Debian: apt-get install cvs, ...) und kann natürlich auch selbst vorgenommen werden (bei UNIX-Sytemen meist nicht anders möglich): http://www.cvshome.org/

Windows:
Die meisten Entwicklungsumgebungen bringen CVS mit. Man kann sich aber auch das "Binary" cvs.exe herunterladen, z.B:

https://ccvs.cvshome.org/files/documents/19/231/cvs-1-11-17.zip
(zu finden unter https://ccvs.cvshome.org/servlets/ProjectDocumentList)

Linux/UNIX/Windows/MacOS:
Ein grafisches Frontend für den Zugriff auf CVS gibt es unter:

Eine Beschreibung, wie man den Zugang unter Windows mit CvsGUI und Putty einrichtet, findet man unter http://anders.fix.no/cvs/wincvs-ssh/ .

2.1.2 Einen SSH-Client installieren, falls noch keiner vorhanden ist.

Linux/UNIX:
Auf den meisten Linux/UNIX-System ist meist schon ein SSH-Client (z.B. OpenSSH: http://www.openssh.org/) installiert.

Windows:
Bei Windows muss natürlich meist erst ein SSH-Client installiert werden. Da wären:

  • ...

2.1.3 Eine SSH-Verbindung zu cvs.cms.hu-berlin.de aufbauen.

ALERT! meist nur einmalig pro verwendeten Client notwendig

  • auf der Kommando-Zeile (Shell oder / MS-DOS-Fenster) folgendes eintippen ([account name] durch den eigenen CMS-Account ersetzen): 
        ssh cvs.cms.hu-berlin.de -l [account name]
   
    bzw.

    ssh2 cvs.cms.hu-berlin.de -l [account name]

  • Wenn nach dem Speichern des Host-Keys gefragt wird, unbedingt mit Ja/yes antworten.

  • Wenn ein Passwort abgefragt wird, bitte das entsprechende Passwort eintippen:
    • entweder zum Account ([account name]) (wenn kein öffentlicher SSH-Key auf dem CVS-Server hinterlegt wurde)
    • oder zum Entsperren des lokalen privaten SSH-Keys (wird nur bei auf dem CVS-Server hinterlegtem SSH-Key abgefragt)

  • Wenn das Einloggen geklappt hat, sollte ein Meldung ähnlich der folgenden ausgegeben werden: 
    #################################################
# Der SSH-Zugang zum CVS-Server ist beschraenkt.#
# Es ist nur erlaubt, mit cvs auf den SSH-      #
# Zugang dieses Servers zuzugreifen.            #
# Ihr Account ist aber gueltig und berechtigt.  #
#################################################
# Bei Fragen und Problemen bitte eine E-Mail an #
#     Webtech <webtech@cms.hu-berlin.de>        #
#################################################
Connection to cvs closed.

2.1.4 Warum ist es wichtig, (einmalig) eine SSH-Verbindung zum Server aufzubauen?

Ganz einfach, damit die lokal verwendete SSH sich den Host-Key abspeichern kann, denn die meisten SSH-Programme fragen den Benutzer, ob der Host-Key gespeichert werden soll (UNBEDINGT MIT "JA/yes" antworten).

Wenn das nämlich noch nicht passiert ist, würde eine Entwicklungsumgebung, die normalerweise nicht mit so einer Frage rechnet, beim Zugriff auf den CVS-Server sicher hängen bleiben.

Außerdem kann man so überprüfen, ob der Account korrekt eingetragen ist.

2.1.5 Warum kann es wichtig sein, einen SSH-Agent laufen zu lassen, wenn man eine Entwicklungsumgebung verwendet?

Dies ist nur interessant, wenn ein SSH-Key auf dem Server hinterlegt wurde.

Die meisten Entwicklungsumgebungen können kein Passwort für die SSH (SSH-Key-Passwort) abfragen, weil oft mit etwas derartigem nicht gerechnet wird. Einige bieten zwar eine Konsole an, in der man dann so etwas eintippen kann, aber eben nur einige.

Ein SSH-Agent fragt einmalig das Passwort für den privaten SSH-Key ab und jede SSH, die danach gestartet wird, verwendet dann den SSH-Agent, um die "Public Key"-Authentifizierung durchzuführen. D.h. man spart sich damit auch die ständige Passwort-Tipperei bei denjenigen CVS-Kommandos, die sich mit dem Server verbinden (checkout, commit, update, import, export ...).

2.2 Welche Zugangsarten bzw. Methoden unterstützt der CVS-Server?

Derzeit wird nur die externe Zugangs-Methode (:ext:... siehe Wie lautet die CVS-Root...) mittels SSH unterstützt.

2.3 Wie lautet die CVS-Root-Angabe für den Zugang zum Repository?

Der übliche CVSROOT-Angabe ist: 
        :ext:[account]@cvs.cms.hu-berlin.de:/cvs/projects/[repository name]
[account] muss durch einen gültigen Benutzer-Account und [repository name] durch den Repository-Namen ersetzt werden.

In der Regel wird auch eine Angabe zur Shell verlangt: ssh bzw. ssh2

Unter Linux/UNIX sind folgende Umgebungsvariablen zu setzen:

# SH/BASH:
CVSROOT=:ext:[account]@cvs.cms.hu-berlin.de:/cvs/projects/[repository name]
export CVSROOT

CVS_RSH=ssh
export CVS_RSH


# CSH/TCSH:
setenv CVSROOT :ext:[account]@cvs.cms.hu-berlin.de:/cvs/projects/[repository name]

setenv CVS_RSH ssh

2.4 Wie importiere ich ein bestehendes Projekt?

Das ist stark abhängig von der verwendeten Entwicklungsumgebung - am besten in die Doku der Entwicklungsumgebung schauen. Wenn die Kommando-Zeilen-Version von cvs direkt verwendet wird:
  1. in das zu importierende Verzeichnis wechseln
  2. ins CVS importieren (Voraussetzung: Umgebungsvariablen CVSROOT/CVS_RSH sind korrekt gesetzt): 
        cvs import -m "<Kleine Info zum neuen Modul>" \
               <modulname - meist der Verzeichnisname> \
               <vendor - z.B. cms> <release tag - z.B. start> 

    # z.B:
    cvs import -m "Ein Test-Modul" test cms start
  3. nach erfolgreichem Import in das darüberliegende Verzeichnis wechseln (cd ..) und das Verzeichnis zur Sicherheit einfach umbenennen
  4. nun kann das Modul ausgecheckt werden (Voraussetzung: Umgebungsvariablen CVSROOT/CVS_RSH sind korrekt gesetzt): 
        cvs co <modulname - meist der Verzeichnisname>

    # z.B:
    cvs co test

2.5 Wie lösche ich Module oder wie benenne ich sie um?

CVS unterstützt derartige Operationen nicht (ein unbeabsichtigtes Löschen würde wohl alles endgültig löschen, bei einzelnen Dateien werden diese wenigstens noch im Attic-Verzeichnis aufgehoben). Wenn Sie Module umbenennen oder löschen wollen, schicken Sie einfach eine E-Mail an webtech@cms.hu-berlin.de und wir kümmern uns dann darum.

TIP Tipps:

  • Auf das Löschen kann man übrigends verzichten, wenn man es einfach nicht mehr benutzen möchten. Will man es aber danach neu anlegen, hilft wirklich nur eine E-Mail an die Webtech-Gruppe.

  • Umbennen kann man auch indirekt, indem in CVSROOT/modules einfach ein neuer Key auf das bestehende (umzubenennende) Verzeichnis eingerichtet wird. Es existiert dann zwar weiterhin, aber es kann auch unter dem neuen Namen ausgecheckt oder exportiert werden.

2.6 Wie konfiguriere ich WinCvs/CvsGui?

Eine kurze (relativ aktuelle) Anleitung findet man unter: http://appel.cms.hu-berlin.de/cvs/wincvshowto.html

Eine (etwas veraltete) Beschreibung, wie man den Zugang unter Windows mit CvsGUI und Putty einrichtet, findet man unter http://anders.fix.no/cvs/wincvs-ssh/ .

2.7 Wie konfiguriere ich den ssh2-Client von SSH Communications Security unter Windows, damit er auch mit Passwort-Authentifizierung funktioniert?

Voraussetzung:
  • Die SSH von SSH Communications Security ist unter C:\Programme\SSH Communications Security\SSH Secury Shell\ installiert
  • Die SSH wurde schon mal gestartet und konfiguriert, sprich das Verzeichnis %USERPROFILE%\Application Data\SSH\ existiert (falls nicht, einfach mit mkdir %USERPROFILE%\Application Data\SSH erzeugen)

Schritt-für-Schritt-Anleitung:

  1. CMD-Shell starten (>Start>Ausführen...>Öffnen: cmd)
  2. Kopiere ssh2_config (folgendes in der CMD-Shell eingeben): 
      copy "C:\Programme\SSH Communications Security\SSH Secure Shell\ssh2_config" "%USERPROFILE%\Application Data\SSH\"
  3. Editiere ssh2_config-Kopie (folgendes in der CMD-Shell eingeben): 
      notepad "%USERPROFILE%\Application Data\SSH\ssh2_config"
  4. und aktiviere folgende Konfiguration in der ssh2_config-Kopie (Kommentar-Zeichen # vor dieser Option löschen):
    Vorher: 
      # AllowedAuthentications publickey,keyboard-interactive,password
    Nachher: 
      AllowedAuthentications publickey,keyboard-interactive,password
  5. und das Abspeichern der ssh2_config-Kopie nicht vergessen.
  6. That's all folks smile

3 Nützliche Links

© CMS | Kontakt: Webtech webtech@cms.hu-berlin.de | geändert am 17.08.2006 um 15:34 Uhr
http://twiki.cms.hu-berlin.de/cvs/cvsbenutzerhowto.html

HU Logo

Computer und
Medienservice

CvsBenutzerHowTo

Impressum