Übersicht. Versionsverwaltung. Ein Lösungsansatz. Wozu Versionsverwaltung? Überblick, CVS. Repository und Arbeitsverzeichnis

Transkript

1 Übersicht Überblick, CVS Repository und Arbeitsverzeichnis Versionsverwaltung Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos 1 2 Wozu Versionsverwaltung? Ein Lösungsansatz Bekannte Situation: Regelmässig alle Zwischenstände sichern Kleine Änderung am Programm Bei auftretenden Problemen können die Änderungen Frage: Unerwünschte Nebenwirkungen in anderen Teilen des Programms Oft erst Tage später entdeckt Welche Änderung ist für das Problem verantwortlich? Was wurde überhaupt geändert? nachvollzogen werden Problem: Bei grösseren Projekten kann das Durchsuchen der Datenbestände ein langwieriges und mühsames Unterfangen sein Arbeiten mehrere Entwickler gemeinsam an einem Projekt, wird es noch schwieriger, die Ursache eines Problems zu identifizieren 3 4

2 Unterschiede zwischen Versionen CVS % diff test1.txt test2.txt 3c3 < koennen die Aenderungen nachvollzogen werden --- > koennen die Aenderungen jederzeit nachvollzogen werden 8c8 < langwieriges und muehsames Unterfangen sein --- > langwieriges Unterfangen sein % CVS: Concurrent Versions System Eines von vielen Versionsverwaltungssystemen Zeichnet den Versionsverlauf gesamter Projekte auf Ermöglicht mehreren Entwicklern den Zugriff auf die Quelltexte Achtet dabei auf die komplette Verzeichnisstruktur der Projekte Open Source Implementierungen für viele Betriebssysteme 5 6 CVS Funktionsweise Übersicht Alle Versionen im so genannten Repository abgelegt Überblick, CVS CVS speichert für Textdateien nur die Unterschiede zwischen den Versionen Repository und Arbeitsverzeichnis Änderungen ins Repository laden Die jüngste und damit am häufigsten benötigte Version wird komplett gespeichert Tags und Branches Teamwork Repository kann sowohl lokal als auch auf einem Server liegen CVS-Tools mit GUI Mehr zu CVS Prinzipielle Arbeitsweise in beiden Fällen gleich Quellen und weitere Infos 7 8

3 Das Repository Das Repository Besteht aus gewöhnlichen Verzeichnissen und Dateien, in denen der Versionsverlauf gespeichert wird Die Daten im Repository dürfen nicht mit den Dateikommandos des Betriebssystems verändert werden Wie dann? Zugriff aufs Repository nur über CVS Regelmässiges Backup des Repository notwendig 9 10 Repository anlegen Repository anlegen Alle Projekte in einem Repository zusammengefasst oder Befehl: init ob eigenes Repository für jedes Projekt Verzeichnisse der obersten Ebene: Module Entwickler, die mehrere kleinere Programme entwickeln, # cd / # mkdir REPOSITORY # cvs -d :local:/repository init verwalten diese eher in einem Repository Bei Entwicklergruppen ist die Situation meist umgekehrt Verwaltungsinformationen legt CVS in einem Verzeichnis CVSROOT im Repository an Vorteil getrennter Repositories: Man kann einzelne Projekte einfach auf einen anderen Rechner verlagern Die versionierten Dateien liegen in eigenen Verzeichnissen im Repository 11 12

4 Verzeichnis importieren import Befehl: import # cd Core # cvs -d :local:/repository/ import -m "alter Kern" Core demo start cvs import: Importing /home/hes//core/ N Core/kernel.c N Core/lib.c No conflicts created by this import Befehl cvs... demo start in einer Zeile Verzeichnis importieren Verzeichnisse ergänzen Der mit -m angegebene Kommentar gibt jeweils eine Beschreibung der Version an CVS zeigt an, welche Dateien es aufgenommen hat: Das "N" vor der Pfadangabe signalisiert eine neue Datei Nachdem die alten Projektdateien importiert wurden, sollte man sie im Quellverzeichnis löschen (mit Backup) Befehl: import 15 16

5 import Arbeiten mit CVS # mkdir Neu # cd Neu # mkdir GUI # mkdir Drivers # cvs -d :local:/repository import -m "neue Projektteile". demo start cvs import: Importing /REPOSITORY/./GUI cvs import: Importing /REPOSITORY/./Drivers No conflicts created by this import Im Wesentlichen drei elementare Vorgänge: Check out: CVS kopiert die Projektdateien aus dem Repository in ein Arbeitsverzeichnis Lokal arbeiten: Der Programmierer arbeitet wie gewohnt mit eigenen Dateien; unabhängig vom Repository Check in: Den neuen Stand in das Repository bringen, um ihn für alle anderen Mitarbeiter sichtbar zu machen Arbeiten mit CVS Arbeitsverzeichnis anlegen Das Arbeitsverzeichnis soll Projekt heissen Zum Bearbeiten wird das Modul Drivers ins Arbeitsverzeichnis geladen Befehl: checkout # mkdir Projekt # cd Projekt # cvs -d :local:/repository checkout Drivers 19 20

6 Arbeitsverzeichnis anlegen Arbeitsverzeichnis anlegen CVS Befehl: # cvs -d :local:/repository checkout Drivers Der durch -d angegebene Pfad verweist auf das Repository Dabei gibt :local: an, dass es auf dem lokalen Rechner liegt Mit :pserver: kann man auf einen CVS Server zugreifen Arbeitsverzeichnis anlegen Lokale Änderungen Im Unterverzeichnis CVS von Drivers legt CVS Im Arbeitsverzeichnis kann nun wie gewohnt zusätzliche Verwaltungsinformationen ab gearbeitet werden Unter anderem: Den Ort, wo das Repository zu Auf das Repository hat das vorerst keine finden ist Auswirkungen Bei allen weiteren cvs-aufrufen im Verzeichnis Drivers muss die Option -d daher nicht mehr angegeben werden Alternative: Den Repository-Ort in der Umgebungsvariable CVSHOME speichern 23 24

7 Übersicht Ins Repository übernehmen Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Nach inhaltlichen Kriterien wird entschieden, wann der aktuelle Stand wieder ins Repository geladen wird Zum Beispiel? Zustand, in dem der Compiler alles fehlerfrei übersetzt Projektspezifische Kriterien (Im Rahmen des Konfigurationsmanagement getroffene Festlegungen) Quellen und weitere Infos Kommando: commit Ins Repository übernehmen Ins Repository übernehmen # cd Projekt # cvs commit -m "Funktionen als Dummy vorhanden" Drivers cvs commit: Examining Drivers RCS file: /REPOSITORY//Drivers/display.c,v done Checking in Drivers/display.c; /REPOSITORY//Drivers/display.c,v <-- display.c new revision: 1.2; previous revision: 1.1 done 27 28

8 Ins Repository übernehmen Ins Repository übernehmen Commit übergibt die Änderungen an den Dateien an CVS Die modifizierte Version von display.c ist nun offiziell im Repository Man hätte auch direkt nur die veränderte Datei angeben können # cd Projekt/Drivers # cvs commit display.c CVS erteilte die Revisionsnummer 1.2 Jede Datei hat ihre eigene Geschichte Um sicherzugehen, dass man nichts vergisst, empfiehlt sich aber ein Commit über das ganze Verzeichnis Alle Dateien werden unabhängig voneinander versioniert Nur tatsächlich veränderte Dateien werden im Repository aktualisiert Ins Repository übernehmen Ins Repository übernehmen Die Option -m beschreibt die Änderungen: Nach dem Commit kann man einfach mit den Dateien Was wurde geändert? weiterarbeiten Sind Fehler beseitigt worden? Die Dateien sind nach einem Commit im Arbeitsver- Ist eine neue Funktion hinzugekommen? zeichnis nicht gesperrt, wie dies bei einigen anderen Hier sollte man im eigenen Interesse etwas Sinnvolles Versionsverwaltungssystemen der Fall ist eintragen (hilft später, die einzelnen Versionen zu Die nächste Version wird auf die gleiche Weise ins unterscheiden) Repository geladen Vergisst man es, öffnet CVS einen Editor zum Eintragen des Dann sind beide Versionen im Repository verfügbar Kommentars (der in der Umgebungsvariable EDITOR oder CVSEDITOR angegeben ist) 31 32

9 Ins Repository übernehmen Dateien hinzufügen # cd Projekt # cvs commit -m "Erste Funktionen implementiert" Drivers cvs commit: Examining Drivers RCS file: /REPOSITORY//Drivers/display.c,v done Checking in Drivers/display.c; /REPOSITORY//Drivers/display.c,v <-- display.c new revision: 1.3; previous revision: 1.2 done Annahme: Einige Funktionen werden in die Datei lowlevel.c ausgelagert Beim Commit ignoriert CVS diese Datei aber zunächst Die neue Datei muss zunächst beim CVS angemeldet werden Kommando: add Dateien hinzufügen Was braucht es noch? # cvs add lowlevel.c cvs add: scheduling file `lowlevel.c' for addition cvs add: use 'cvs commit' to add this file permanently Bis jetzt: Repository anlegen, Projektverzeichnis ins Repository laden, Änderungen übernehmen Was noch? Auf ältere Versionen zurückgreifen Unterschiede zwischen Versionen ansehen Die neue Datei wird dadurch als Teil des Moduls angemeldet, zunächst aber nur im Arbeitsverzeichnis Konflikte bei mehrfacher Änderung der gleichen Datei auflösen In das Repository kommt die Datei erst beim nächsten Commit

10 Unterschiede Unterschiede Angenommen, man möchte wissen, was von einer Version zu einer anderen an einer Datei geändert wurde Dazu dient der Befehl diff Ohne Versionsangabe wird die Datei im Arbeitsverzeichnis mit der aktuellen Version im Repository verglichen Ein Parameter -r : die Version wird mit der Arbeitsversion verglichen # cvs diff display.c Index: display.c ============================================ RCS file: /REPOSITORY/Drivers/display.c,v retrieving revision 1.3 diff -r1.3 display.c 14,17c14,15 < Mask_ul = 0xff > StartBit_uc; < Mask_ul &= ( 0xff < RevEndBit_uc ); < Zwei Parameter -r: diese Versionen vergleichen < Value_ul = ( Value_ul < RevEndBit_uc ) & Mask_ul; Bei vielen Änderungen sinnvoll, die Ausgabe in eine Datei umzuleiten > Value_ul = ( Value_ul < RevEndBit_uc ) & ( 0xff >> StartBit_uc ); > Value_ul = ( Value_ul < RevEndBit_uc ) & ( 0xff << RevEndBit_uc ); Unterschiede Alte Version ansehen # cvs diff -r 1.1 -r 1.2 display.c Index: display.c ============================================ RCS file: /REPOSITORY/Drivers/display.c,v retrieving revision 1.1 retrieving revision 1.2 diff -r1.1 -r1.2 13a14,17 > Mask_ul = 0xff > StartBit_uc; > Mask_ul &= ( 0xff < RevEndBit_uc ); > > Value_ul = ( Value_ul < RevEndBit_uc ) & Mask_ul; Mit Checkout kann auch eine bestimmte Version einer Datei aus dem Repository geholt werden Sinnvollerweise macht man das in einem anderen Verzeichnis, damit die Arbeitsversion nicht überschrieben wird # mkdir temp # cd temp # cvs -d :local:/repository/ checkout -r 1.1 Drivers/display.c U Drivers/display.c 39 40

11 Übersicht Releases Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos Jede Datei wird einzeln versioniert Für ein Release muss man aus dem Repository Quelltexte unterschiedlicher Versionsnummern zusammenstellen Dazu versieht CVS alle Dateien eines Projektstandes neben ihrer Versionsnummer mit einem Etikett (Tag) Das müssen nicht unbedingt die jeweils neuesten Versionen der Dateien sein Befehl: tag Releases Releases # cvs tag release_1_0 cvs tag: Tagging Core T Core/kernel.c T Core/lib.c cvs tag: Tagging Drivers T Drivers/display.c T Drivers/lowlevel.c cvs tag: Tagging GUI T GUI/menu.c T GUI/window.c Die Versionsnummern der Dateien, die CVS kennzeichnet, entsprechen dabei den im Arbeitsverzeichnis vorhandenen Versionen Dabei werden sowohl lokale Änderungen als auch zwischenzeitliche Änderungen auf dem Repository nicht berücksichtigt Will man lokale Änderungen in das Release aufnehmen, muss man davor ein Commit durchführen 43 44

12 Releases Releases Alternative: Befehl rtag Arbeitet direkt im Repository und benötigt kein Arbeitsverzeichnis Benötigt aber die Angabe der zu markierenden Module Kennzeichnet den aktuellen Stand im Repository # cvs -d :local:/repository rtag internal_1_1 Core Drivers GUI cvs rtag: Tagging Core cvs rtag: Tagging Drivers cvs rtag: Tagging GUI Mit Hilfe der Tags ist es einfach, zu einem späteren Zeitpunkt ein ganz bestimmtes Release des Projektes zurückzuholen Ein Checkout mit der Angabe des gewünschten Tags liefert genau den Stand, der damit markiert wurde In grösseren Projekten erstellt ein eigener Projektmitarbeiter, der Integrator, die einzelnen Releases (Release Management) Dabei wird überprüft, ob die Dateien wirklich zusammenpassen und das Release freigegeben werden kann Releases Branches # cvs checkout -r release_1_0 Core Drivers GUI Üblicherweise nehmen Projekte keinen so geradlinigen cvs checkout: Updating Core Weg, wie bisher beschrieben U Core/kernel.c U Core/lib.c cvs checkout: Updating Drivers U Drivers/display.c U Drivers/lowlevel.c cvs checkout: Updating GUI U GUI/menu.c U GUI/window.c Projekte können sich irgendwann in zwei oder mehr Entwicklungszweige spalten Mögliche Gründe? Für einen Kunden soll eine spezielle Version der Software erstellt werden Für ein bestehendes Release wird ein Bugfix nötig, bevor das nächste Release fertig ist 47 48

13 Branches Branches Beispiel: Im release_1_0 muss ein Fehler korrigiert werden (die neuesten Versionen seien noch nicht in einem Zustand, der bald freigegeben werden kann) Also wird von dem release_1_0 eine Verzweigung (Branch) angelegt Die Verzweigung wird dabei mit einem neuen Tag release_1_0_branch versehen # cvs rtag -b -r release_1_0 release_1_0_branch Core Drivers GUI cvs rtag: Tagging Core cvs rtag: Tagging Drivers cvs rtag: Tagging GUI Anschliessend wird der Ausgangspunkt des neuen Zweigs mit checkout in ein neues Arbeitsverzeichnis geladen Dies ist der Ausgangspunkt des neuen Entwicklungszweigs Branches Branches # mkdir BugfixWork Nun kann an dem Bugfix gearbeitet werden # cd BugfixWork # cvs checkout -r release_1_0_branch Core Drivers GUI cvs checkout: Updating Core Zwischenversionen können mit commit ins Repository geladen werden M Core/kernel.c M Core/lib.c Der Hauptzweig ist davon völlig unabhängig cvs checkout: Updating Drivers M Drivers/display.c M Drivers/lowlevel.c cvs checkout: Updating GUI M GUI/menu.c M GUI/window.c 51 52

14 Branches Status Nachdem der Fehler beseitig ist (in der Datei lowlevel.c), wird die korrigierte Version ins Repository geladen # cvs commit -m "Bugfix" cvs commit: Examining. Checking in lowlevel.c; /REPOSITORY/Drivers/lowlevel.c,v <-- lowlevel.c new revision: ; previous revision: 1.2 done # cvs status -v lowlevel.c =============================================================== File: lowlevel.c Status: Up-to-date Working revision: Tue Apr 17 16:11: Repository revision: /REPOSITORY/Drivers/lowlevel.c,v Sticky Tag: release_1_0_branch (branch: 1.2.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: release_1_0_branch (branch: 1.2.2) release_1_0 (revision: 1.2) Branches Join Wenn nach dem Bugfix im Hauptzweig weitergearbeitet Angenommen, der Bugfix soll nun auch im Hauptzweig werden soll, muss nur das lokale Arbeitsverzeichnis nachgeführt werden gewechselt werden Mithilfe eines Join können die Änderungen eines Da CVS dort interne Verwaltungsinformationen ablegt, anderen Zweigs in den aktuelle Arbeitsversion landen beim commit die Daten automatisch im übernommen werden Hauptzweig Dabei kann auch ein Konflikt entstehen: Die gleichen Solange man getrennte Verzeichnisse verwendet, ordnet Teile einer Datei wurden unterschiedlich modifiziert CVS die Versionen immer dem richtigen Ast zu In diesem Fall muss manuell nachgebessert werden 55 56

15 Join Join # cvs update -j release_1_0_branch cvs update: Updating Core cvs update: Updating Drivers RCS file: /REPOSITORY//Drivers/lowlevel.c,v retrieving revision 1.2 retrieving revision Merging differences between 1.2 and into lowlevel.c cvs update: Updating GUI Nach dem Join (update -j) ist nur das Arbeitsverzeichnis auf dem neuesten Stand Erst ein nachfolgendes commit bringt die zusammengeführte Datei ins Repository Davor sollte man diese Version ausführlich testen Trotz des Zusammenführens beider Äste bleiben alle Infos über den Branch vollständig im Repository Das Repository enthält immer die ganze Projektgeschichte Übersicht Teamwork Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos Eine der Stärken von CVS: Mehrere Entwickler können gemeinsam an einem Projekt arbeiten CVS erlaubt es sogar, dass zwei Mitarbeiter gleichzeitig an derselben Datei arbeiten Es koordiniert die Arbeit erst beim commit, also wenn die Dateien ins Repository geladen werden Derjenige, der die geänderte Datei als Erster ins Repository lädt, hat beim checkin keine Probleme 59 60

16 Teamwork Teamwork Hat allerdings jemand anderes die Datei bereits aktualisiert, Solange beide unterschiedliche Teile des Quelltextes gibt CVS beim commit eine Meldung aus: verändert haben, genügt ein Update: # cvs update display.c # cvs commit display.c cvs commit: Up-to-date check failed for `display.c' cvs [commit aborted]: correct above errors first! RCS file: /REPOSITORY/EINFACH/display.c,v retrieving revision 1.4 retrieving revision 1.5 Merging differences between 1.4 and 1.5 into display.c M display.c In diesem Fall muss man die Datei zuerst mit dem Repository abgleichen Danach genügt ein Commit, um die geänderte Version ins Repository zu laden Teamwork Teamwork Haben mehrere Entwickler dieselbe Stelle in einer Datei In der Datei display.c werden die Konfliktstellen entsprechend verändert, kann CVS die Versionen nicht zusammenführen markiert: Es besteht ein Konflikt, den die Entwickler auflösen müssen # cvs update display.c RCS file: /REPOSITORY/EINFACH/display.c,v retrieving revision 1.3 retrieving revision 1.5 Merging differences between 1.3 and 1.5 into display.c rcsmerge: warning: conflicts during merge cvs update: conflicts found in display.c <<<<<<< display.c Mask_ul = 0xff << RevEndBit_uc; Mask_ul &= ( 0xff > StartBit_uc ); ======= Mask_ul = ( 0xff > StartBit_uc ) & ( 0xff << RevEndBit_uc ) >>>> 1.5 C display.c 63 64

17 Teamwork Teamwork Die ursprüngliche Version wurde zuvor nach.#display.c.1.3 kopiert Kopiert man diese nach display.c und sendet sie mit commit ins Repository, fliegen die Änderungen des Kollegen aus dem Projekt (sie bleiben aber als vorletzte Version im Repository) Das Auflösen solcher Konflikte ist immer mit Arbeit verbunden Daher möglichst vermeiden Geeignete Projektorganisation / Verteilung der Verantwortungsbereiche Sinnvoller: Sich abzusprechen, welche Änderungen ins Repository übernommen werden sollen Arbeit mit CVS Arbeit mit CVS Normalerweise hat jeder Entwickler sein klar abgegrenztes Welche Versionen jeweils ins Repository geladen werden, Aufgabengebiet wird projektspezifisch festgelegt Regelmässig holt man die Arbeit der anderen durch den In der Regel gelten bestimmte Minimalanforderungen: Befehl update aus dem Repository Ist eine Aufgabe erledigt, bringt ein Commit das Ergebnis ins Repository Update -> Bearbeiten -> Commit Alle im Repository vorhandenen Varianten müssen übersetzbar sein Alle per Tag zu einer Release zusammengefassten Versionen müssen zusammenpassen 67 68

18 Übersicht CVS Tools mit GUI Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos Es gibt verschiedene CVS Tools mit GUI Voraussetzung für eine Arbeit mit diesen Tools ist es aber trotzdem, die Funktionsweise von CVS verstanden zu haben Beispiele: WinCVS und MacCVS TortoiseCVS Integration mit Windows Explorer

19 73 74 CVS Tools mit GUI TkCVS TkCVS Setzt auf TCL/TK auf, Plattform übergreifend Oberfläche kommt nicht sehr elegant daher CVL - Concurrent Versions Librarian Unter Mac OS X oder unter Windows mit WebObjects Integriert sich bei Bedarf in Apples ProjectBuilder KDE-Programm Cervisa

20 CVL Diff CGI Scripts Linux KDE Zum Zugriff auf CVS-Repository übers Web gibt es auch verschiedene CGI Scripts für die Darstellung des Repository-Inhalts im Browser Zugriff auf Logs und einzelne Versionen Meist nur lesender Zugriff Cervisia 79 80

21 cvsweb CVS Tools in IDEs CVS ist in viele Entwicklungsumgebungen integriert Beispiele Eclipse Netbeans Projectbuilder Emacs kdevelop Emacs Übersicht Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos 83 84

22 Binärdateien Download vom CVS-Repository Differenzen kann CVS nur bei Textdateien ermitteln Binärdateien werden daher jedes Mal komplett ins Repository kopiert Daher muss beim Verwenden von Binärdateien (Word, Bilder, usw.) mit grossem Speicherplatzverbrauch gerechnet werden Generell sollten generierte Dateien, die nicht manuell bearbeitet werden, nicht ins Repository kommen Viele Open-Source-Projekte setzen CVS ein Dabei befindet sich das Repository auf einem Server im Internet Ein solcher Server ist Sourceforge.net, die Heimat vieler Open-Source-Projekte Wenn man Software von einem CVS Server laden möchte, stellt man die Umgebungsvariable CVSROOT so ein, dass sie die Login-Daten für das Repository enthält Download vom CVS-Repository Download vom CVS-Repository Anschliessend muss man sich beim Server anmelden: Dann kopiert ein checkout die Dateien des Projektes auf den lokalen Rechner: # cvs login (Logging in to anonymous@cvs.project.server.net) CVS password: # cvs -z3 checkout Projekt Der Benutzer anonymous hat meist ein leeres Passwort Der Name des Projektes ist oft auch der Name des zu holenden Verzeichnisses Die Option -z3 legt fest, dass CVS die Daten komprimiert überträgt 87 88

23 CVS für die Web-Entwicklung Besonderheit: Web-Applikationen benötigen eine bestimmte Umgebung: Web-Server, Script-Interpreter etc. Wenn die Applikationen bzw. Website im Arbeitsbereich der einzelnen Entwickler auch getestet werden sollen, muss diese Umgebung dort auch verfügbar sein Beispiel, wie CVS in der Web-Entwicklung eingesetzt werden könnte CVS für die Web-Entwicklung Andere Versionsverwaltungstools Vorteile: Subversion: Mehrere Entwickler können relativ unabhängig voneinander an einem gemeinsamen Projekt arbeiten Alle Änderungen werden aufgezeichnet und man kann jederzeit zu einer früheren Version zurückkehren Entwickler können an verschiedenen Arbeitsplätzen (zum Beispiel auch zuhause) arbeiten Nachteile: Viele Binärdateien wie Bilder, Flash Datenbankanbindung: DB-Inhalt nicht in der Versionsverwaltung The goal of the Subversion project is to build a revision control system that is a compelling replacement for CVS in the open source community Most current CVS features. Directories, renames, and file meta-data are versioned Commits are truly atomic Efficient handling of binary files Branching and tagging are cheap (constant time) operations$ Parseable output 91 92

24 Andere Versionsverwaltungstools Übersicht Meta-CVS: Version control system built around CVS Directory structure versioning User-friendly file type handling Simple branching and merging Support for symbolic links and meta-data Überblick, CVS Repository und Arbeitsverzeichnis Änderungen ins Repository laden Tags und Branches Teamwork CVS-Tools mit GUI Mehr zu CVS Quellen und weitere Infos Quellen und weitere Infos Andreas Bleul, Herbert Schmid: Versionskontrolle - Quellcode mit CVS verwalten und organisieren, c't 11/2001 S. 226 ff Homepage von CVS CVS Manual CVS Book 95