Versionsverwaltung. Dr.-Ing. Matthias Sand. Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg SS 2009

Transkript

1 Versionsverwaltung Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg SS 2009 Versionsverwaltung 1/

2 Inhalt Motivation RCS CVS SVN Dezentrale Systeme Versionsverwaltung 2/

3 Source-Code Verwaltung Ursprüngliches Problem Früher ging s doch schon mal! Warum denn jetzt nicht mehr? Was hab ich geändert?!? Versionsverwaltung 3/

4 Source-Code Verwaltung (2) Lösung Alte Versionen der Sourcen/Dokumente aufbewahren. Frage: Wie bewahrt man alte Versionen sinnvoll auf? Vielleicht: Kapitel-1_ tex, Kapitel-1_ tex, Kapitel-1_final.tex, Kapitel-1_really_final.tex??? Oder: mit spezialisierten Werkzeugen, wie RCS (Revision Control System), CVS (Concurrent Versions System), SVN (Subversion),... Versionsverwaltung 4/

5 Source-Code Verwaltung (3) Grundideen Arbeitskopie und verwaltete Versionen getrennt ( Repository ), erzeuge Versionsschritte durch vom Benutzer ausgelöste Aktionen ( Commit, Check-In ), speichere zu jeder Version nur die Änderungen gegenüber der vorigen Version, Zeitpunkt der Änderungen, (automatisch generierte) Versionsnummer, Kommentar des Bearbeiters,... Versionsverwaltung 5/

6 RCS (Revision Control System) Eigenschaften Urahn der Versionsverwaltungssysteme, Prinzip: sperre und bearbeite. Repository Name der normalen Datei X Name der RCS-Datei (Repository) X,v (oder RCS/X,v) Arbeitskopie und Repository liegen parallel im Dateisystem. Versionsverwaltung 6/

7 RCS (Revision Control System) (2) Operationen Auschecken (zum Ansehen / Compilieren; read-only): co [-r <revision>] <dateiname> Auschecken (zum Ändern, Lock setzen): co [-r <revision>] -l <dateiname> Änderungen einchecken (Lock löschen): ci -u <dateiname> Änderungen ansehen: rcsdiff [-u] <dateiname> Versionsverwaltung 7/

8 Verteiltes Entwickeln Situation Mehrere Personen entwickeln gleichzeitig ein (großes) Softwareprojekt weiter. Problem Wie können Konflikte beim Bearbeiten gleicher Dateien vermieden werden? Versionsverwaltung 8/

9 Verteiltes Entwickeln (2) Lösungsansätze Alle verwenden gleichen Source-Baum gegenseitiges Sperren = Vorgehen bei RCS. Jeder verwendet eigenen Source-Baum späteres Zusammenführen der Änderungen ( Merge ) = Vorgehen bei CVS. Versionsverwaltung 9/

10 Verteiltes Entwickeln (3) Idee bei CVS Jeder hat einen eigenen Satz Sourcen. Jeder ändert seine Sourcen lokal. Änderungen können an das (entfernte) Repository zurückgeschrieben werden. Änderungen anderer Entwickler können auf die eigenen Sourcen übertragen werden. Dabei können zwar nicht automatisch auflösbare Konflikte entstehen, aber niemals im Repository, nur in der Arbeitskopie einzelner Benutzer! Versionsverwaltung 10/

11 CVS (Concurrent Versions System) Source-Repository ${REP}/CVSROOT/... ${REP}/<module>/... Verwaltungsinfo RCS-Dateien für Paket <module> Anlegen eines CVS-Repositories $ mkdir ${REP} $ mkdir ${REP}/CVSROOT $ mkdir ${REP}/<module> Versionsverwaltung 11/

12 CVS (Concurrent Versions System) (2) Auschecken der Sourcen $ c v s d ${REP} checkout <module> Updaten der Sourcen $ cd <module> $ c v s [ n ] update [ l ] [< d a t e i >... ] Versionsverwaltung 12/

13 CVS (Concurrent Versions System) (3) Ändern der Dateien $ v i <d a t e i >... $ c v s [ n ] add <d a t e i / d i r e c t o r y >... $ c v s [ n ] remove <d a t e i / d i r e c t o r y >... Versionsverwaltung 13/

14 CVS (Concurrent Versions System) (4) Einchecken der Änderungen $ c v s [ n ] commit [ l ] [< d a t e i >... ] Änderungen ansehen $ c v s [ n ] d i f f [ l ] [ u ] [< d a t e i >... ] Versionsverwaltung 14/

15 CVS (Concurrent Versions System) (5) Verzeichnisse Verzeichnisse werden sofort zum Repository hinzugefügt: $ mkdir s r c $ c v s add s r c D i r e c t o r y /tmp/ p r o j /Module/ s r c added to the r e p o s i t o r y Sie werden für andere Bearbeiter erst sichtbar nach: $ c v s update d Verzeichnisse werden nie wieder gelöscht; leere Verzeichnisse können aber aus der Arbeitskopie entfernt werden durch: $ c v s update dp Versionsverwaltung 15/

16 CVS (Concurrent Versions System) (6) Großer Nachteil von CVS Umbenennen von Dateien geht nur so: $ mv o l d. c new. c $ c v s remove o l d. c $ c v s add new. c $ c v s commit Änderungsgeschichte von old.c ist bei new.c nicht mehr sichtbar! (Theoretisch auch möglich: Repository-Surgery ; gefährlich!) Versionsverwaltung 16/

17 CVS und SVN Hauptunterschied CVS versioniert jede Datei einzeln am gegebenen Ort (Ort-vor-Zeit-Prinzip), Beschreibung von Projektversionen nur mittels Datum oder Tags möglich, SVN versioniert immer das gesamte Repository (Zeit-vor-Ort-Prinzip), SVN-Revisionen immer für alle Dateien gleich. Versionsverwaltung 17/

18 CVS und SVN (2) Weitere Unterschiede Bei SVN können Kopien von Dateien mit gleicher Versionsgeschichte erstellt werden ( billige Kopie ), SVN kann auch Verzeichnisse verwalten, SVN erkennt die meisten Binärdateitypen automatisch (CVS: cvs add -kb image.png), SVN speichert sein Repository in einer Datenbank (fsfs oder Berkeley DB) ggf. Kompatibilitätsprobleme, Struktur des Quellbaums nicht sofort aus Repository erkennbar, Repository-Surgery kaum noch möglich, in SVN können einmal eingecheckte Dateien praktisch nicht rückstandsfrei wieder entfernt werden. Versionsverwaltung 18/

19 SVN (Subversion) Source-Repository In Datenbankformat innerhalb eines Verzeichnisses. Anlegen eines Repositories $ svnadmin c r e a t e f s t y p e f s f s db / path / to / r e p o s i t o r y Auschecken der Sourcen $ svn co f i l e : / / / path / to / r e p o s i t o r y [ / path / to / module ] Versionsverwaltung 19/

20 SVN (Subversion) (2) Dateien oder Directories hinzufügen/löschen $ svn add remove f i l e s... Einchecken der Änderungen $ svn commit f i l e s... Konflikte auflösen $ svn r e s o l v e d f i l e s... Versionsverwaltung 20/

21 Dezentrale Systeme Hauptunterschied Kein zentrales Repository! Jeder Benutzer hat eine Kopie des gesamten Repositorys viele Aktionen ohne Netzwerkzugriff möglich. Weitere Eigenschaften (Je nach konkretem Vertreter verschieden, meist nicht notwendigerweise mit Dezentralität verknüpft.) Offizielle Repositories nur per Konvention, kryptographische Sicherheit der Projektgeschichte, Vielfalt an Protokollen zur Repository-Synchronisation, Anbindung traditioneller Versionsverwaltungssysteme,... Versionsverwaltung 21/

22 Dezentrale Systeme (2) Typische Vertreter git (Linux-Kernel-Entwicklung), bazaar (kennt auch dedizierte zentrale Repositories),... Versionsverwaltung 22/