xwolf.de|com

SiteMenu

Navigation über die verschiedenen Projekt-Domains

• Portal Die Eingangsseite von xwolf.de. Hier finden sich Artikel, Informationen und Hilfen allgemein zu Webworking
• CGI Das ehemalige Realm of CGI. Hier finden sich diverse CGI-Skripten und Hilfen, sowie Tutorials zur CGI-Programmierung
• Grafik & Design Ein Tutorial für Webdesign.
• txtPL txtPL ist ein plattform- und sprachunabhängiger für Textdateien und Templates
• Privates Private HOmepage von Wolfgang Wiese
• Blog Das WebLog von xwolf

Menü

Inhalt dieser Site

• Startseite
• Neues
• Über xwolf
• Impressum
• Projekte & Partner

• Artikel
• Glosse & Kommentare
• Dialog

• Suche
• Seitenindex
• Inhalt
• Druckansicht

Ansicht

Individuelle Benutzerkonfiguration für die Site.

• Blue Night
• Morning
• Scott's Design

A A A A

Webseiten und Dokumente verwalten mit CVS und TortoiseCVS

Wolfgang Wiese (www.xwolf.de, xwolf@xwolf.de), August 2003

[Einleitung] [Installation und Einrichtung] [Ein Projekt einchecken] [Ein Projekt auschecken, Änderungen einchecken & Lokale Version aktualisieren] [Mehrere Projekt als Module verwalten] [Marken (Tags) definieren] [Branches und Subbranches] [Sonstige Funktionen von TortoiseCVS] [Ausblick & Referenzen]

8. Branches und Subbranches

   Bei größeren Projekten kann es vorkommen, daß es notwendig ist, verschiedene Entwicklungszweige (Zweig = Branch in Englisch) zu führen. Hierunter versteht man Dateien, die sich von einer bestimmten Version des normalen Entwicklungsbaumes der CVS-Repository abspalten und so eine eigene Entwicklungslinie erzeugen. Bei einem Webprojekt kann man sich dies am folgendem Beispiel vorstellen.

   Eine Unternehmswebsite besteht aus einem Grunddesign welches normalerweise für alle Abteilungen gilt. Jedoch hat das Unternehmen nun auch ein Intranet, also eine Form des Webauftrittest welche nur für Mitarbeiter aufrufbar ist. Um das Intranet vom normalen Webauftritt zu unterscheiden zu können, wurde beschlossen, daß die Hintergrundfarbe der Seiten im Intranet, sowie diverse Logos anders zu gestalten sind.
   Die Grundstruktur und das Grunddesign soll jedoch auf die aktuelle Version des normalen Webauftritts aufbauen.

   Um dies zu erreichen, hat man zwei Möglichkeiten:

   • Kopieren der aktuellen Version des Webauftritts und erstellen eines neuen CVS-Projektes hieraus
   • Einbau einer Verzweigung

   Im Software-Bereich ist die Erstellung von Branches üblich, wenn es darum geht, für unterschiedliche Kunden verschiedene Formen der Individualsoftware zu estellen, die jedoch auf eine Basissoftware zurückgehen.
   Ein anderes Beispiel sind die Entwicklungszweige, die beispielsweise der Browser Mozilla hat. Dort werden verschiedene Generationen des Browsers mit Hilfe von Branches abgearbeitet, die dann dazu genutzt werden, eigene Softwarelinien aufzubauen:

   Bild 24. Branches am Beispiel der Mozilla Roadmap

   Dabei wird jede neue Version des Browsers als eigener Branch definiert, der sich aber aus einem Hauptzweig abspaltet. Die eigentliche Entwicklung zu neuen Browsern erfolgt immer auf den Hauptzweig, während auf den neuen Zweig mit der jeweiligen veröffentlichten Version des Browsern nur noch Bugfixes gemacht werden.

   Bei TortoiseCVS wird ein neuer Branch über die Funktion CVS >> Verzweigen... definiert. (Aufruf über Kontextmenü und die Funktion CVS.

   Bild 25. Projekt verzweigen

   Auf der Unix-Shell würde dies so aussehen: cvs tag -b -c Intranet index.html

   Wenn man ein Branch mit TortoiseCVS erstellt, muß man jedoch darauf achten, daß dieser Zweig zunächst nur im Repository erstellt wird. Die Dateien, die man ausgecheckt hat, bleiben in dem Zweig wo sie vorher waren; Wenn bisher kein Zweig existierte, dann sind sie Teil des immer vorhandenen Hauptzweigs (HEAD).
   Um auf den Dateien des neuen Zweigs zu arbeiten, muss man diese zuerst neu auschecken. Dies geschieht mit Hilfe der Funktion Speziell aktualisieren...

   Bild 26. Speziell aktualisieren...

   Auf der Unix-Shell würde dies so aussehen: cvs update -d -P -r Intranet

   Diese Funktion von TortoiseCVS wird übrigens auch verwendet um Versionen, die durch Tags gekennzeichnet wurden, auszuchecken. Leider erkennt man den Unterschied zwischen Tags und Branches nur schwer, wenn man sich die Namen über Liste holen aufruft. Es ist daher empfehlenswert, hier eine gewisse Namenssyntax aufzubauen. Eine schönere Möglichkeit, sich die aktuellen Branches oder Tags auszuchecken, bietet die Funktion Revisionsgraph. Diese Funktion kann man über das Kontextmenü einer Datei aufrufen. Man erhält hier den gesamten Baum aus Tags und Branches angezeigt und kann mit Hilfe des Kontextmenüs innerhalb des Baumes navigieren (sprich: Die jeweils gesuchte Version oder den gesuchten Zweig auschecken).

   Bild 27. Revisionsgraph einer Datei

   Für Bild 27 hab ich mit Hilfe der Verzweigen-Funktion und darauf folgende Updates/Commits einige Branches aufgebaut und darin auch weitere Versionen eingespielt. Dabei hab ich insgesamt 4 Branches aufgemacht. Zwei Branches gehen aus von der Version 1.5: STABLE und Intranet. Im Branch STABLE wurde die Datei index.html noch einmal geändert und erhielt dadurch eine neue Version 1.5.2.1.
   Beim Branch Intranet (Version 1.5.4.*) wurde die Datei noch zweimal weiter entwickelt und wurde dann nochmals mit einem Unterbranch Intranet-Projekt (Version 1.5.4.2.2.*) verzweigt.
   Zuallerletzt wurde dann auch noch später die Version 1.6 des Hauptzweiges noch einmal verzweigt durch einen Branch EnglischerAuftritt.

   Hinweis zu den Revisionsnummern: Bei der Erstellung eines neuen Branches wird die Revisionsnummer des Entwicklungszweigs genommen aus der der Branch erstellt wird und daran durch Punkt getrennt zwei weitere Nummern angehängt. Die Zählung der ersten Nummer beginnt dabei mit 2, da die Versionsnummer 0 und 1 von CVS für andere Zwecke reserviert sind (Vgl: Magic branch numbers und Tracking third-party sources).

   Tipps und Hinweise zum Thema Branches:

   Wenn man sich die Branches eines Projekts (egal of Software oder Webauftritt) nicht in Form einer Grafik vor Augen führt hat man teilweise große Verständnis- und Organisationsprobleme. Man sollte daher bei der Nutzung von Branches unbedingt zwei Dinge tun:

   1. Versuchen Sie soweit möglich, eine Grafik mit den Branches zu erstellen.
      

      TortoiseCVS liefert bereits automatisch eine sehr nützliche Grafik hierzu. Nutzen Sie diese!

   2. Benutzen Sie eingängige Namen für die Branches. Erstellen Sie eine Namenskonvention.
      

      Mögliche Namenskonventionen sind abhängig von der Art des CVS-Projektes. Bei einem Webprojekt sollte man ggf. die Zweige nach den Projektnamen der Websites benennen oder nach dessen Funktionen. Zum Beispiel bei mehrsprachigen Webauftritten wären dies die Namen Englisch, Spanisch, usw. Bei dem Customizing von Software für Kundenzwecke könnte man die Namen der Kunden als Branchnamen nutzen. Und bei allgemeiner Software wiederum, die als OpenSource entwickelt wird, kann man Namenskonventionen wie bei Mozilla verwenden, wo die Versionsnummern des Hauptzweigs den Namen definieren. (Obwohl auch bei Mozilla der Trend dahin geht, jedem Browser einen Projektnamen zu geben).

      Bild 28. Revisionsgraph mit Tags und Branches

      Bild 25 zeigt die Nutzung von Tags in einem Entwicklungsbaum mit Branches. Tags werden durch einen etwas eckiger geformten Kasten definiert, der durch eine dünne Linie mit der jeweiligen Version der Datei verbunden ist. Branches werden durch eine 8-eckige Box definiert, die dann auch eine Versionslinie begründet.

      Ich selbst hab bei der Erstellung der obigen Branches Anfangs einen kleinen Fehler gemacht. Haben Sie ihn bemerkt?
      Ich hatte im Kapitel über Tags (Marken) bereits eine Namenskonvention definiert. Dort war bereits der Name STABLE enthalten. Hier hab ich ihn diesen dummerweise dann nochmals für ein Branch definiert. Dies führt dann automatisch zu Verwirrung...
      Wie auch immer: Sie sollten bei einer Namenskonvention für Branches beachten, daß diese nicht mit der Namenskonvention für Tags kollidiert. Beide Namenskonventionen sollten parallel Funktionen, da Tags auch innerhalb von Branches definiert werden können.

   3. Tags springen über Branches.
      

      Wenn beispielsweise der Tag TEST zunächst im Hauptzweig gesetzt ist und später nochmal gesetzt (also verschoben) wird, wechselt der Tag in den Zweig, auf dessen Datei er gesetzt wurde, auch wenn dieser Zweig einen anderen Namen hat.
      Es kann nur einen geben...

   4. Branches lassen sich mergen
      

      Weiter oben haben wir beim normalen Update gesehen, daß sich unterschiedliche Versionen von Dateien auch mergen lassen können. Dies ist auch für Branches möglich.

      Über die Funktion Zusammenführen... lassen sich Dateiversionen aus unterschiedlichen Zweigen mergen. Nach dem Mergen muß man jedoch, wie auch bei der Update-Funktion unter Umständen Konflikte von Hand lösen.

      Bild 29. Zweige mergen

      In der Regel sollte man Projekte nur selten oder eigentlich nie mergen. Es ist der Sinn von Entwicklungszweigen, sich auseinander zu entwickeln. Wie auch immer - es kann aber der Fall auftreten, das Entwickler eines Zweigs etwas gemacht haben, was die Entwickler im anderen Zweig auch haben wollen. Wenn es dann quellcode-technisch geht, kann man sich ein Merge überlegen.

      Bild 30. Statusfenster beim Zweige mergen

      Aber in der Praxis ist der Aufwand den Merge durchzuführen oft höher, als den neuen Code einfach von Hand in Form einer neuen, ungemergten Version in den Zweig einzuspielen.
      In anderen Worten: Finger weg vom Mergen, wenn man nicht genau weiß was man tut!