Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.
Sie haben mittlerweile vielleicht festgestellt, dass Subversion äußerst flexibel ist. Da Zweigen und Tags derselbe Mechanismus zugrunde liegt (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, den Inhalt eines
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“; hier ist ein Beispiel für ein solches Layout:
/
paint/
trunk/
branches/
tags/
calc/
trunk/
branches/
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 andere Benutzer nehmen. Ihr Jonglieren kann Benutzer mit bestehenden Arbeitskopien verwirren. 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 474 übertragen.
Tipp | |
---|---|
Erinnern Sie sich aus dem vorhergehenden Abschnitt, dass sie eine Fehlermeldung bekommen, wenn Sie versuchen, Ihre Arbeitskopie zu aktualisieren und diese sich auf einen Ort im Projektarchiv bezieht, der gelöscht wurde: $ svn up Aktualisiere ».«: Zielpfad »/calc/branches/my-calc-branch« existiert nicht In dieser Situation müssen Sie nur Ihre Arbeitskopie auf einen noch existierenden Ort wechseln: $ svn sw ^/calc/trunk D src/whole.c U src/real.c A src/integer.c U . Aktualisiert zu Revision 474. |
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, können 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 ^/calc/branches/my-calc-branch@473 \ ^/calc/branches/my-calc-branch \ -m "my-calc-branch wiederhergestellt." Revision 475 ü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 Software-Entwicklung 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 ^/calc/trunk ^/calc/branches/stable-1.0 \ -m "Stabilen Zweig für Projekt calc angelegt." Revision 476 ü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
übertragen
werden. Das heißt, während auf dem Stamm weitergearbeitet
wird, pickt jemand selektiv Fehlerbehebungen hinüber 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.