Sie haben mittlerweile vielleicht festgestellt, dass Subversion äußerst flexibel ist. Da Zweigen und Tags derselbe Mechanismus zugrundeliegt (Verzeichniskopien) und weil Zweige und Tags im normalen Dateisystem auftauchen, finden viele Leute Subversion einschüchternd. Es ist beinahe zu flexibel. In diesem Abschnitt machen wir einige Vorschläge, wie Sie Ihre Daten im Laufe der Zeit organisieren und verwalten können.
Es gibt einige empfohlene Standards, ein Projektarchiv zu
organisieren. Die meisten Leute erzeugen ein
trunk
-Verzeichnis, um die Hauptlinie der
Entwicklung aufzunehmen, ein
branches
-Verzeichnis für Zweig-Kopien und
ein tags
-Verzeichnis für Tag-Kopien.
Falls ein Projektarchiv nur ein Projekt beinhaltet, werden oft
diese Verzeichnisse auf der obersten Ebene angelegt:
/trunk /branches /tags
Falls ein Projektarchiv mehrere Projekte enthält, teilen Administratoren das Projektarchiv üblicherweise nach den Projekten ein (lesen Sie in „Planung der Organisation Ihres Projektarchivs“ mehr über „Projekt-Wurzelverzeichnisse“):
/paint/trunk /paint/branches /paint/tags /calc/trunk /calc/branches /calc/tags
Natürlich ist es Ihnen freigestellt, diese verbreiteten Strukturen zu ignorieren. Sie können alle möglichen Variationen erzeugen, die am besten für Sie oder Ihr Team funktionieren. Denken Sie daran, dass es, wie auch immer Sie sich entscheiden, nicht für die Ewigkeit sein muss. Sie können jederzeit Ihr Projektarchiv umorganisieren. Da Zweige und Tags gewöhnliche Verzeichnisse sind, kann der Befehl svn move sie nach Belieben verschieben oder umbenennen. Die Umstrukturierung ist einfach eine Sache von serverseitigen Verschiebebefehlen. Wenn Ihnen der Aufbau des Projektarchivs nicht zusagt, jonglieren Sie einfach mit den Verzeichnissen herum.
Obwohl es einfach ist, Verzeichnisse zu verschieben, sollten Sie Rücksicht auf Ihre Benutzer nehmen. Ihr Jonglieren kann verwirrend für Benutzer mit bestehenden Arbeitskopien sein. Falls ein Benutzer eine Arbeitskopie eines bestimmten Projektarchiv-Verzeichnisses hat, könnte Ihre svn move-Operation den Pfad von der letzten Revision entfernen. Wenn der Benutzer beim nächsten Mal svn update aufruft, wird ihm mitgeteilt, dass die Arbeitskopie einen Pfad repräsentiere, der nicht mehr bestehe, so dass er gezwungen ist, mit svn switch auf den neuen Ort umzuschalten.
Eine weitere nette Eigenschaft des Subversion-Modells ist
die Möglichkeit, Zweigen und Tags eine begrenzte Lebensdauer
zu geben, so wie jedem anderen versionierten Objekt. Nehmen
wir beispielsweise an, dass Sie letztendlich Ihre Arbeit auf
dem persönlichen Zweig des calc
-Projektes
abschließen. Nachdem Sie all Ihre Änderungen zurück nach
/calc/trunk
gebracht haben, braucht Ihr
privater Zweig nicht mehr herumzuliegen:
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Veralteten Zweig des Projekts calc gelöscht." Revision 375 übertragen.
Nun ist Ihr Zweig verschwunden. Selbstverständlich ist er
nicht wirklich verschwunden: das Verzeichnis fehlt einfach in
der HEAD
-Revision, so dass es niemanden
mehr ablenken kann. Wenn Sie svn checkout,
svn switch oder svn list
verwenden, um sich eine frühere Revision anzusehen, werden Sie
immer noch Ihren alten Zweig sehen.
Falls es nicht ausreichen sollte, im gelöschten
Verzeichnis zu stöbern, können Sie es jederzeit wieder
zurückholen. Das Wiederbeleben von Daten in Subversion ist
sehr einfach. Falls ein gelöschtes Verzeichnis (oder eine
gelöschte Datei) wieder nach HEAD
gebracht
werden soll, verwenden Sie einfach svn copy
zum Kopieren aus der alten Revision:
$ svn copy http://svn.example.com/repos/calc/branches/my-calc-branch@374 \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "my-calc-branch wiederhergestellt." Revision 376 übertragen.
In unserem Beispiel hatte Ihr persönlicher Zweig eine
relativ kurze Lebensdauer: Sie haben ihn vielleicht angelegt,
um einen Fehler zu beseitigen oder eine neue Funktion
einzubauen. Wenn Ihr Arbeitspaket abgeschlossen ist, kann auch
der Zweig geschlossen werden. In der Softwareentwicklung ist
es allerdings auch üblich, zwei „Haupt“-Zweige zu
haben, die für lange Zeit nebeneinander bestehen. Es ist zum
Beispiel an der Zeit, eine stabile Version des
calc
-Projektes zu veröffentlichen, und
Sie wissen, dass es wohl noch ein paar Monate dauern wird, um
Fehler aus der Software zu entfernen. Sie wollen weder, dass
dem Projekt neue Funktionen hinzugefügt werden, noch möchten
Sie alle Entwicklern auffordern, das Programmieren
einzustellen. Stattdessen erstellen Sie einen
„stabilen“ Zweig der Software, auf dem sich nicht
viel verändern wird:
$ svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/stable-1.0 \ -m "Stabilen Zweig für Projekt calc angelegt." Revision 377 übertragen.
Nun können Entwickler die neuesten (oder experimentellen)
Funktionen /calc/trunk
hinzufügen,
während Sie zum Grundsatz erklären, dass ausschließlich
Fehlerbehebungen an
/calc/branches/stable-1.0
übergeben
werden. Das heißt, während auf dem Stamm weitergearbeitet
wird, überträgt jemand selektiv Fehlerbehebungen auf den
stabilen Zweig. Selbst wenn die Software von hier bereits
ausgeliefert worden ist, werden Sie diesen Zweig
wahrscheinlich noch für eine lange Zeit pflegen – das
heißt, so lange, wie Sie diese Auslieferung beim Kunden
unterstützen werden. Wir werden das im nächsten Abschnitt
näher erörtern.