| Zeile 1: | Zeile 1: | ||
Versionsverwaltungen machen das Leben einfacher. Nicht nur für Betriebssystementwickler, sondern auch für jede andere Entwicklungsart. Nicht nur für Einzelpersonen, sondern auch und insbesondere für Gruppen. Systeme für die Versionsverwaltung nennen sich VCS(Version Control System) oder SCM(Source Code Managementsystem). | Versionsverwaltungen machen das Leben einfacher. Nicht nur für Betriebssystementwickler, sondern auch für jede andere Entwicklungsart. Nicht nur für Einzelpersonen, sondern auch und insbesondere für Gruppen. Systeme für die Versionsverwaltung nennen sich VCS(Version Control System) oder SCM(Source Code Managementsystem). | ||
| − | = Hauptaufgaben = | + | == Hauptaufgaben == |
Eine Versionsverwaltung erfüllt eine handvoll nützliche Aufgaben, die Entwicklern das Leben leichter machen. | Eine Versionsverwaltung erfüllt eine handvoll nützliche Aufgaben, die Entwicklern das Leben leichter machen. | ||
* Protokollierung der Änderung. Jede Änderung am Quelltext kann nachvollzogen werden, egal von wem, an was, oder wieso. | * Protokollierung der Änderung. Jede Änderung am Quelltext kann nachvollzogen werden, egal von wem, an was, oder wieso. | ||
| Zeile 8: | Zeile 8: | ||
* Koordinieren von Entwicklungszweigen, z.B. wenn eine alte Funktionalität komplett ersetzt werden soll, aber der Hauptzweig während dieser Änderung weiterhin ungestört funktionieren soll. | * Koordinieren von Entwicklungszweigen, z.B. wenn eine alte Funktionalität komplett ersetzt werden soll, aber der Hauptzweig während dieser Änderung weiterhin ungestört funktionieren soll. | ||
| − | = Mechanismen = | + | == Mechanismen == |
Diese Aufgaben können auf verschiedene Arten umgesetzt werden. Dabei unterscheidet sich insbesondere, wie die Versionsverwaltung aufgebaut ist. Mögliche Varianten: | Diese Aufgaben können auf verschiedene Arten umgesetzt werden. Dabei unterscheidet sich insbesondere, wie die Versionsverwaltung aufgebaut ist. Mögliche Varianten: | ||
* '''Lokale Versionsverwaltungen''' laufen auf dem Entwicklerrechner. Fremdentwickler gibt es hierbei in der Regel nicht, eine Koordination zwischen Entwicklern ist nicht nötig. | * '''Lokale Versionsverwaltungen''' laufen auf dem Entwicklerrechner. Fremdentwickler gibt es hierbei in der Regel nicht, eine Koordination zwischen Entwicklern ist nicht nötig. | ||
| Zeile 14: | Zeile 14: | ||
* '''Dezentralisierte Versionsverwaltungen''' sind quasi die Hybriden. Jeder Entwickler hält eine komplette Kopie der gesamten Versionshistorie vorrätig, wie bei einer Lokalen Verwaltung. Aber im Gegensatz hierzu können Änderungen auch direkt in fremde Systeme übertragen werden. Beispiele sind [[Mercurial]] und das populäre [[git]]. | * '''Dezentralisierte Versionsverwaltungen''' sind quasi die Hybriden. Jeder Entwickler hält eine komplette Kopie der gesamten Versionshistorie vorrätig, wie bei einer Lokalen Verwaltung. Aber im Gegensatz hierzu können Änderungen auch direkt in fremde Systeme übertragen werden. Beispiele sind [[Mercurial]] und das populäre [[git]]. | ||
| − | = Konzepte = | + | == Konzepte == |
Das arbeiten mit einer Versionsverwaltung basiert auf gewissen Konzepten, welche hier näher erläutert werden sollen. | Das arbeiten mit einer Versionsverwaltung basiert auf gewissen Konzepten, welche hier näher erläutert werden sollen. | ||
| − | == Lock-Modify-Write == | + | === Lock-Modify-Write === |
Lock-Modify-Write ist quasi der ursprüngliche Arbeitsvorgang mit einer Versionsverwaltung unter mehreren Benutzern. Wenn ein Entwickler etwas ändern will, markiert er die Datei auf der zentralen Verwaltung als gesperrt (sog. lock). Dann kann er alle Änderungen nach seinen Wünschen durchführen, andere Entwickler bekommen während der Lock besteht keinen Schreibzugriff auf betroffene Objekte. Nach Abschluss der Arbeiten werden die Änderungen zurück übertragen und der Lock aufgehoben. Nun können wieder andere an der Datei arbeiten. | Lock-Modify-Write ist quasi der ursprüngliche Arbeitsvorgang mit einer Versionsverwaltung unter mehreren Benutzern. Wenn ein Entwickler etwas ändern will, markiert er die Datei auf der zentralen Verwaltung als gesperrt (sog. lock). Dann kann er alle Änderungen nach seinen Wünschen durchführen, andere Entwickler bekommen während der Lock besteht keinen Schreibzugriff auf betroffene Objekte. Nach Abschluss der Arbeiten werden die Änderungen zurück übertragen und der Lock aufgehoben. Nun können wieder andere an der Datei arbeiten. | ||
| − | == Copy-Modify-Merge == | + | === Copy-Modify-Merge === |
Copy-Modify-Merge ist die Alternative zu Lock-Modify-Write. Jedem Entwickler wird direkt gestattet an seiner lokalen Kopie Änderungen durchzuführen. Beim zurück Übertragen der Änderungen prüft die Verwaltung selbstständig ob es Kollisionen zwischen den Änderungen gibt. Ist dies der Fall wird dies dem späteren Entwickler zusammen mit den vorherigen Änderungen gemeldet dass der Vorgang abgebrochen werden muss. Der Entwickler hat dann die Gelegenheit seine und die fremden Änderungen in Einklang zu bringen (Merge), um eine neue Version übertragen zu können. Manche Versionsverwaltungen versuchen auch mehrere Änderungen alleine in Einklang zu bringen, was allerdings nicht immer funktioniert. Vorteil ist, das problemlos mehrere Entwickler auch den gleichen Quelltext bearbeiten können - solange jeder an einem anderen Teil arbeitet und es nicht zu Änderungen an der gleichen Codestelle kommt. | Copy-Modify-Merge ist die Alternative zu Lock-Modify-Write. Jedem Entwickler wird direkt gestattet an seiner lokalen Kopie Änderungen durchzuführen. Beim zurück Übertragen der Änderungen prüft die Verwaltung selbstständig ob es Kollisionen zwischen den Änderungen gibt. Ist dies der Fall wird dies dem späteren Entwickler zusammen mit den vorherigen Änderungen gemeldet dass der Vorgang abgebrochen werden muss. Der Entwickler hat dann die Gelegenheit seine und die fremden Änderungen in Einklang zu bringen (Merge), um eine neue Version übertragen zu können. Manche Versionsverwaltungen versuchen auch mehrere Änderungen alleine in Einklang zu bringen, was allerdings nicht immer funktioniert. Vorteil ist, das problemlos mehrere Entwickler auch den gleichen Quelltext bearbeiten können - solange jeder an einem anderen Teil arbeitet und es nicht zu Änderungen an der gleichen Codestelle kommt. | ||
| − | == Branching und Tagging == | + | === Branching und Tagging === |
Branching und Tagging sind die Konzepte die sich mit der Koordinierung verschiedener Entwicklungszweige und spezifischen Versionen beschäftigen. | Branching und Tagging sind die Konzepte die sich mit der Koordinierung verschiedener Entwicklungszweige und spezifischen Versionen beschäftigen. | ||
* '''Branching''' wird verwendet, um größere Änderungen einzuführen. Es wird ein neuer Branch gebildet, der den gesamten bisherigen Quelltext enthält. Hier können größere Bereiche rundum erneuert werden, ohne dass andere Entwickler im Hauptentwicklungszweig (trunk) mit Problemen zu rechnen haben. Sind die Änderungen abgeschlossen, wird der Branch in den Hauptzweig überführt, dabei auftretende Probleme (z.B. durch eine geänderte API) sollten dabei behoben werden (Merge). | * '''Branching''' wird verwendet, um größere Änderungen einzuführen. Es wird ein neuer Branch gebildet, der den gesamten bisherigen Quelltext enthält. Hier können größere Bereiche rundum erneuert werden, ohne dass andere Entwickler im Hauptentwicklungszweig (trunk) mit Problemen zu rechnen haben. Sind die Änderungen abgeschlossen, wird der Branch in den Hauptzweig überführt, dabei auftretende Probleme (z.B. durch eine geänderte API) sollten dabei behoben werden (Merge). | ||
* '''Tagging''' bezeichnet den Vorgang, einem bestimmten Entwicklungszustand einen gewählten Namen zu verleihen. Dies wird insbesondere bei Veröffentlichungen gemacht. Generell sollte ein Tag nicht nachträglich geändert werden, falls dies doch notwendig ist, sollten nur Bugfixes vorgenommen werden, keinesfalls aber neue Features hinzugefügt werden. | * '''Tagging''' bezeichnet den Vorgang, einem bestimmten Entwicklungszustand einen gewählten Namen zu verleihen. Dies wird insbesondere bei Veröffentlichungen gemacht. Generell sollte ein Tag nicht nachträglich geändert werden, falls dies doch notwendig ist, sollten nur Bugfixes vorgenommen werden, keinesfalls aber neue Features hinzugefügt werden. | ||
| − | = Systeme = | + | == Systeme == |
Momentan (<small>Stand Anfang 2009)</small>) sind die meistgenutzten Systeme im OpenSource-Bereich [[git]] und [[Subversion]], etwas selter trifft man auch [[Mercurial]] oder das etwas ältere [[CVS]]. Dabei sind sowohl Subversion als auch CVS für einen Zentralen Aufbau ausgelegt (können aber auch lokal gut verwendet werden), git hingegen folgt einem vollständig dezentralen Ansatz. | Momentan (<small>Stand Anfang 2009)</small>) sind die meistgenutzten Systeme im OpenSource-Bereich [[git]] und [[Subversion]], etwas selter trifft man auch [[Mercurial]] oder das etwas ältere [[CVS]]. Dabei sind sowohl Subversion als auch CVS für einen Zentralen Aufbau ausgelegt (können aber auch lokal gut verwendet werden), git hingegen folgt einem vollständig dezentralen Ansatz. | ||
| − | == Bekannte Projekte und ihr eingesetztes VCS == | + | === Bekannte Projekte und ihr eingesetztes VCS === |
{| {{Prettytable}} | {| {{Prettytable}} | ||
!Projekt !! VCS | !Projekt !! VCS | ||
| Zeile 41: | Zeile 41: | ||
|} | |} | ||
| − | = Weblinks = | + | == Weblinks == |
*[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Einführung in dezentrale Versionsverwaltung] ''(english)'' | *[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Einführung in dezentrale Versionsverwaltung] ''(english)'' | ||
[[Kategorie:Versionsverwaltung]] | [[Kategorie:Versionsverwaltung]] | ||
[[Kategorie:Werkzeuge]] | [[Kategorie:Werkzeuge]] | ||