Subversion


Unterpunkte dieser Seite

Terminologie
Der Arbeitszyklus eines Benutzers, der alleine arbeitet
Der Arbeitszyklus eines Benutzers, der in einem Team arbeitet
Ein SVN Repository anlegen
import - Ein Projekt in das Repository einfügen (importieren)
checkout
commit
update
add
status
Properties
Dateien und Verzeichnisse mit SVN ignorieren
Mit dem Sopra SVN Server arbeiten
Branching
Herausfinden in welchen Bereichen des Repository man schreiben darf
SVN Server einrichten unter DSL

Frequently Asked Questions

Wie kann ich den Inhalt eines Repository anzeigen lassen ?

Wie kann ich die Revision der Verzeichnisse und Dateien in meinem working copy anzeigen lassen ?

Was passiert falls ich lokal eine Datei verändert aber noch nicht commited habe und diese Datei aber im Repository zwischenzeitlich auch verändert worden ist ? Gehen meine Änderungen bei einem Update verloren ?

Ich habe eine Datei ohne einen svn Befehl aus meinem working copy gelöscht. Wie passe ich die Struktur des working copy und des Repositorys jetzt so an, das die Datei auch aus den administrativen .svn Ordnern dieser beiden Orte verschwindet ?

Ich möchte ein update meines working copy durchführen und erhalte den Fehler svn: Failed to add directory 'docu/Entwurf': object of the same name already exists

Wie kann ich herausfinden, welche Dateien in meinem working copy noch nicht mit svn add geadded wurden ?

Wie kann ich mit svn bestimmte Dateien und Ordner ignorieren, so das sie bei einem add oder commit nicht mit ins Repository übertragen werden ?

Wie kann ich mit svn einen Ordner und alle Unterordner unter Versionskontrolle stellen ?

Wie kann ich mit svn eine Binärdatei unter Versionskontrolle stellen, so dass svn bei einem update keine Unterscheidungen in die Datei hineinschreibt ?

Terminologie
working copy Ein working copy ist ein Unterverzeichnisbaum aus dem Verzeichnisbaum des Repository, der aus dem Repository ausgechekt wurde und auf der Festplatte liegt, so das der Entwickler an den Dateien im working copy arbeiten kann. Jedes Verzeichnis eines working copy enthällt einen .svn ordner, indem svn alle administrativen Informationen wie z.B. die Versionsnummern der Dateien und Verzeichnisse speichert, das Datum der letzten Änderung an einer Datei und den Inhalt einer Datei zu einer bestimmten Versionsnummer. Man kann ein working copy auf der Festplatte verschieben ohne das SVN durcheinander kommt. SVN liest alle Informationen die es benötigt aus dem administrativen .svn Verzeichnissen, daher kann man ein working copy ohne Probleme verschieben. Man kann ein working copy einfach löschen, SVN kommt dadurch nicht durcheinander. Man sollte allerdings niemals den Inhalt eines working copys mit einem File Browser oder den Befehlen des Betriebsystems verändern. Möchte man Dateien innerhalb eines working copys verschieben oder in ein anderes working copy kopieren, so muss man die Befehle svn copy und svn move verwenden, damit die Änderungen in die .svn Verzeichnisse aufgenommen werden. Hat man neue Dateien erstellt und möchte man diese neue Dateien in das Repository und das working copy aufnehmen so muss man den Befehl svn add verwenden. Möchte man Dateien aus einem Repository und einem working copy entfernen, so muss man den Befehl svn delete verwenden. Es gibt den Befehl svn mkdir um Verzeichnisse im working copy zu erzeugen.

Der Arbeitszyklus eines Benutzers, der alleine arbeitet
  1. Erzeugen eines Repository
    2. Als allererstes muss ein Repository erstellt werden. Ein Repository ist ein Verzeichnis im Dateibaum, welches von SVN verwaltet wird. Zur Verwaltung muss SVN Informationen über den Inhalt des Repositories speichern. Daher werden von SVN im Repository Dateien und Verzeichnisse automatisch angelegt. Man soll das Repository nicht manuell verarbeiten sondern nur indirekt über die Programme svn und svnadmin.
    SVN Verwaltet in einem Repository Verzeichnisse und Dateien des Benutzers. SVN kennt das Konzept des Projektes nicht. Ein Projekt muss in SVN also durch ein Verzeichnis im Repository simuliert werden. Dies ist das Vorgehen, das in den SVN Manuals vorgeschlagen wird. Es ist also eine Verantwortlichkeit des Benutzers, die Projektverwaltung selbst vorzunehmen. SVN unterstützt ihn nur dabei, es verwaltet das Verzeichnis des Projektes und die eventuel darin befindlichen Unterverzeichnisse und Dateien. In diesem Dokument steht der Begriff Projekt für ein Verzeichnis.
  2. Erzeugen eines neuen Projektes im Repository
    3. Beginnen Sie damit, in einem temporären Verzeichnis auf der Festplatte ein Projekt vorzubereiten, das dann über den svn import Befehl ins Repository übernommen werden wird. Es ist zur Konvention bei der Arbeit mit svn geworden, ein Projekt auf oberster Ebene in drei Hauptverzeichnisse zu untergliedern. Es gibt das Verzeichnis trunk, in das Sie alle ihre Quellcodedateien einfügen. Des weiteren die Verzeichnisse branches und tags, die zu Begin leer bleiben. (Diese Aufteilung hat etwas mit Branching und Merging zu tun.) Erzeugen Sie also ein temporäres Verzeichnis /home/bischowg/temp/Project_1 und darin die drei Verzeichnisse trunk, braches und tags und legen Sie den Quellcode in das Verzeichnis trunk. Nachdem Sie alles vorbereitet haben, können Sie das Projekt in das Repsitory importieren. Das importieren ist eine einmalige Angelegenheit. Nachdem ein Projekt importiert wurde, erfolgt der weitere Zugriff auf das Projekt durch die Befehle checkout, commit und update.
    Es ist wichtig zu wissen, das Sie von nun an nicht mehr mit dem Dateien im temporären Verzeichnis, aus dem Sie importiert haben, weiterarbeiten sollen. Statt dessen müssen Sie das gerade eben importierte Projekt aus dem Repository auschecken, also aus dem Repository herausholen und in ein Verzeichnis ablegen in dem Sie dann am Projekt arbeiten können. Sie fragen sich vielleicht, wieso denn das ? Ich hab das Projekt doch so schön hier im Temporären Verzeichnis vorbereitet, warum kann ich nicht gleich loslegen, warum muss ich allen Code doppelt auf die Festplatte ziehen ? Warum immer ich ? Die Antwort auf diese Frage ist, das SVN administrative Informationen über die Versionierung der Dateien eines Projektes und deren Änderungsstatus gegenüber den Dateien im Repository in .svn Verzeichnissen speichern muss und das nicht etwa im Repository sondern lokal auf ihrer Festplatte in dem Ordner in dem Sie mit den Dateien des Projektes arbeiten. Diese Administrativen .svn Verzeichnisse sind in dem temporären Verzeichnis, aus dem Sie importiert haben, nicht vorhanden ! Kurz gesagt: ein svn import erzeugt noch kein working copy im Quellordner des imports.
    Daher ist dieses temporäre Verzeichnis für die Arbeit mit SVN völlig ungeeignet. Ein Verzeichnis, das neben dem Quellcode noch die administrativen .svn Verzeichnisse enthält, wird working copy genannt. Sie erhalten ein working copy nur durch einen checkout des Projektes ! Der Arbeitszyklus mit SVN ist also in den ersten drei Schritten für den normalen Menschenverstand doppelt und dreifach überflüssig, wenn man ihn aber von der technischen Seite her betrachtet nur logisch und leider unumgänglich.
    Wenn Sie sich den Inhalt des SVN Repository mit dem Linux Befehl ls anzeigen lassen, werden sie den Ordner ihres Projektes nicht sehen ! Das liegt daran, das SVN ein Datenbank verwendet um die Verzeichnisse und Dateien zu verwalten.
  3. Das erste Auschecken
    4. Um ein working copy zu erhalten, müssen Sie das Projekt zu begin ihrer Arbeit an dem Projekt wenigstens einmal auschecken. Das geschieht mit dem svn checkout Befehl.
  4. Am Projekt arbeiten
    5. Sie arbeiten als Programmierer am Projekt und erzeugen dabei neue Dateien. Neue Dateien bezieht sich auf Dateien, die nach dem initialen commit zum Projekt hinzugekommen sind. Diese Dateien befinden sich noch nicht im Repository und müssen dorthin übertragen werden. Ein svn update Aufruf überträgt nur Dateien ins Repository, die bereits unter Versionskontrolle stehen. Das ist für Ihre neuen Dateien noch nicht der Fall. Mit dem Befehl svn add stellt man Dateien unter Versionskontrolle. Diese Dateien werden beim nächsten svn commit und fort an immer ins Repository übertragen (falls sie sich geändert haben). Falls Sie sich umentschieden haben und eine Datei doch nicht ins Repository übertragen wollen, können Sie den svn add Befehl mit dem svn revert Befehl auf die Datei ungeschehen machen.
  5. updaten
    6. Ein einzelner Arbeiter, der nicht in einem Team arbeitet muss niemals ein update durchführen, da es niemanden außer ihm selbst gibt, der Änderungen am Repository durchführen könnte. (In einem Team sieht das natürlich anders aus und dort ist der update Befehl natürlich sehr wichtig.)
  6. Einchecken (commit)
    7. Nachdem man Änderungen am working copy und denn darin befindlichen Dateien vorgenommen hat, kann man die Änderungen ins Repository übernehmen. Dazu muss man das working copy commiten. Dies geschieht mit dem Befehl svn commit.

Der Arbeitszyklus eines Benutzers, der in einem Team arbeitet

 Es reicht ein ursprünglicher checkout um das Repository in ein working copy auf der Festplatte zu spiegeln. Bevor man an einem neuen Arbeitstag anfängt zu arbeiten, sollte man ein update des eigenen working copy durchführen um herauszufinden, ob das Team inzwischen Änderungen an den Dateien vorgenommen hat und um somit selbst auf dem neuesten Stand zu bleiben.
Der Arbeitszyklus eines Mitarbeiters eines Teams unterscheidet sich in der Weise in der man Änderungen commited. Eine Datei die lokal verändert wurde und gleichzeitig auch von einem Teammitglied verändert wurde und bereits ins Repository commited wurde, kann erst nach einem update commited werden.

Ein SVN Repository anlegen

 Man erzeugt ein neues Repository nicht mit dem svn Befehl sondern mit dem Befehl svnadmin. 
svnadmin create /home/bischowg/svnrepository

import - Ein Projekt in das Repository einfügen (importieren)

 Sie benötigen, das Projekt in einem Verzeichnis auf der Festplatte und ein SVN Repository, in das Sie das Projekt importieren können. 
svn import /home/bischowg/temp/project_1 file:///home/bischowg/svnrepository/project_1 -m "initial import"
Der Schalter -m "text" fügt einen Kommentar zu diesem Import hinzu. Vergessen Sie nicht im file:/// Teil des Befehls hinten ein extra Verzeichnis für das Project anzugegeben damit ein Unterverzeichnis im Repository für das Projekt angelegt wird und nicht die gesammten Projektdateien einfach so ins Repository abelegt werden. In diesem Beispiel wurde projekt_1 verwendet. (Dies ist zwar nicht notwendig für die Verwendung von SVN aber es ist notwendig, damit Sie diesem Beispiel weiterhin folgen können.
ACHTUNG:svn import erzeugt aus den lokalen Dateien (hier: /home/bischowg/temp/project_1) kein working copy ! Man kann also mit den lokalen Dateien nicht mit SVN arbeiten. Sie sind unversioniert. Man muss erste einen checkout des Projektes aus dem Repository machen um ein working copy zu erhalten.

checkout

 
svn checkout http://svn.example.com/repos/calc
Woher weiß svn wohin es die Dateien auschecken soll bzw. wo wird svn die working copy erstellen ?
svn checkout file:///home/bischowg/svnrepository/project_1 /home/bischowg/temp/testFolder
Der Befehl svn checkout besitzt als ersten Parameter den Unifom Resource Locator zum Repository. Der zweite Parameter ist der Pfad zum Verzeichnis in das das Projekt ausgecheckt wird. In unserem Beispiel befindet sich also nach dem auschecken in dem Verzeichnis testFolder die Verzeichnisse branches, tags und trunk, sowie das administrative Verzeichnis .svn in jedem dieser Unterverzeichnisse. Selbstverständlich werden auch die Dateien, die im trunk Verzeichnis lagen mit ausgecheckt und können manipuliert werden, wodurch sie eine neue Versionsnummer erhalten. Es ist nicht notwending ein working copy so zu nennen, wie das Verzeichnis des Projektes im Repository. Wenn das Projekt im Repository also project_1 heist und in ein Verzeichnis namens favoriteMusic ausgecheckt wird, so stört das die Funktionalität von SVN überhaupt nicht. Durch die administrativen .svn Verzeichnisse, kann SVN die Zuordnung zum richtigen Projekt im SVN Repository vornehmen und kommt nicht durcheinander.
Falls man nicht das gesammte Verzeichnis eines Projektes sondern nur ein Unterverzeichnis auschecken möchte, so kann man im svn checkout Befehl den Pfad zum Unterverzeichnis angegeben, das man auschecken möchte.

Acces URLs
file:/// direct repository access on local disk. MIND THE THREE SLASHES.
http:// access via WebDAV protocol to Subversion-aware Apache server
https:// same as http:// but with SSL encryption
svn:// access via custom protocol to an svnserve server
svn+ssh:// same as svn:// but through an SSH tunnel

Commit

 ACHTUNG: Falls beim commiten erscheint: "svn: 'project_1' is not a working copy" so hat man probiert ein Verzeichnis zu commiten, das keine administrativen .svn Verzeichnisse besitzt und damit laut Definition kein working copy darstellt. SVN kann nur working copys commiten, da in den .svn Ordnern die Information enthalten ist, wo sich das repository befindet und welche Revision die Datei hatte als sie ursprünglich ausgecheckt wurde.
Ein commit ist das Übertragen der eigenen Änderungen ins Repository. Bei jedem commit muss eine logmessage angegeben werden. Dazu kann man den --message bzw. -m Parameter verwenden. Alternativ kann die logmessage aus einer Datei eingelesen werden, dazu benutzt man den --file Parameter und gibt hinter --file den Pfad zur Datei an, die die logmessage enthällt. Die dritte Möglichkeit ist es weder --message noch --file zu verwenden. Dann wird sich ein Editor öffnen in den man die logmessage eintragen muss. Man speichert dann im Editor ab und verlässt den Editor. Falls man die logmessage im Editor gespeichert hat, nimmt SVN den commit direkt vor. Falls man die logmessage nicht gespeichert hat, zeigt SVN nach dem Verlassen des Editors eine Auswahl an Möglichkeiten an. Darunter kann man auswählen, das man den commit abbrechen möchte. 
svn commit button.c -m "Kommentar verhindert Öffnen eines Editors"
Woher weiß svn wohin committed werden soll ? .svn ordner vielleicht.
Ja, genau. Durch das .svn Verzeichnis verbindet SVN die Dateien und Verzeichnisse des working copy mit dem Richtingen Verzeichnis im Repository.
Falls es Konflikte zwischen den eigenen Änderungen und neuen Änderungen im Repository gibt, wird der commit abgebrochen und SVN zeigt einen Hinweis auf Konflikte an. Man muss nun manuell den svn update Befehl ausführen und die Konflikte lösen. Danach führt man svn resolved auf und kann die Änderungen nun commiten. ACHTUNG: Nach einem commit besitzt das Repository eine neue inkrementierte einheitliche Revisionsnummer. Das eigene working copy jedoch hat nun eine gemischte Revisionsnummer, d.h. verschiedene Dateien und Verzeichnisse haben unterschiedliche Revisionsnummern. Um das working copy auf den gleichen Stand zu bringen wie das Repository muss man svn update durchführen. Ein commit führt also nur eine update der Dateien durch, die im Vergleich zum Repository geändert worden sind. Alle anderen Dateien ohne Änderungen werden von einem commit nicht geupdated, dazu muss man svn update durchführen. Die gemischte Revisionsnummer des working copy hat einfluss auf alle informationsanzeigenden Befehle von SVN. Wenn man also die aktuellsten Informationen angezeigt haben möchte, so sollte man immer zuerst ein update durchführen.

update

 Um ein working copy auf den neuesten Stand zu bringen, navigiert man in das working copy und führt dort folgenden Befehl aus 
svn update
Man muss nicht den Pfad des working copy angegeben falls man sich gerade im working copy befindet. SVN findet durch die administrativen Ordner .svn heraus, woher es die neueste Version aus dem Repository beziehen kann und welche Dateien auf den neuesten Stand gebracht werden müssen.
Alternativ kann man auch den Pfad des working repository als paramter zum svn update Befehl angeben. Es ist dann egal wo man sich im Verzeichnisbaum befindet, wenn man den svn update Befehl ausführt, er probiert mit Pfadangabe immer, das angegebene working directory auf den neusesten Stand zu bringen. 
svn update /home/bischowg/temp/testFolder

add

 Mit dem add Befehl stellen Sie Dateien unter Versionskontrolle. Die geaddeten Dateien werden nicht sofort ins Repository übernommen sondern erst beim nächsten svn commit. Der add Befehl muss angewendet werden, wenn Sie lokal während eines Arbeitstages neue Dateien in ihrem working copy erzeugen, die dann noch nicht im Repository vorhanden sind aber dorthin übertragen werden sollen.

status

 Mit dem Befehl svn status kann man die Änderungen anzeigen lassen, die seit dem letzten update oder checkout vorgefallen sind. Falls es überhaupt keine Änderungen gibt, so wird svn update keine Ausgabe produzieren, es sagt nicht mal, das es keine Änderungen gab. Möchte man das Verhalten von svn status so anpassen, das es den Status aller Dateien angibt auch wenn es keine Änderungen gab, so muss man die --verbose oder -v Option verwenden. Falls es jedoch Änderungen gegeben hat, so gibt svn status die Datei an, die Änderungen enthällt und zusätzlich einen Code, der die Änderungen näher beschreibt. 
svn status --verbose
status gibt durch ein Fragezeichen als Zustandscode die Dateien an, die noch nicht unter der Versionskontrolle stehen, auf die also noch kein svn add Befehl ausgeführt worden ist.

Properties

 svn propset, propedit, prodel, proplist und propget

Dateien und Verzeichnisse mit SVN ignorieren

 Bei diesem Thema gibt es einen Konflikt. Man kann mit svn propedit svn:ignore eine Reihe von Schemas auf ein Verzeichnis legen, das bereits unter Versionskontrolle steht. Diese Schemas werden verwendet um die Ausgabe des svn status Befehls auf die Dateien zu beschränken, die nicht den Schemas genügen. svn add --force ignoriert die Schemas und fügt einfach rekursiv alle Dateien und Unterordner eines Verzeichnises hinzu. Durch den switch --force steigt es dabei auch rekursiv in alle Ordner ab, die bereits unter Versionskontrolle stehen. Die ignore-Patterns haben daher nur einfluss auf svn status nicht aber auf svn add --force. Das svn-book.pdf ist auf der Seite 136 bzw 153 ungenau geschrieben: 
The list of patterns to ignore is also used by svn add and svn import. Both of these operations involve
asking Subversion to begin managing some set of files and directories. Rather than force the user to pick
and choose which files in a tree she wishes to start versioning, Subversion uses the ignore patterns to determine
which files should not be swept into the version control system as part of a larger recursive addition
or import operation.
Dies bezieht sich nur auf die globale svn:ignore Property Liste nicht auf das svn:ignore Property, das man auch ein spezielles Verzeichnis gelegt hat ! svn add --force fuegt alles hinzu was es in die Finger bekommen kann, auch ignorierte Dinge ! Das erzeugt den Konflikt : Wenn man beim Programmieren in tiefen, tiefen, finsteren Unterverzeichnissen Dateien erzeugt hat, diese unter Versionskontrolle stellen will und gleichzeitig auch Verzeichnisse hat, die man nicht unter Versionskontrolle stellen will, so darf man nicht svn add --force ausführen. Warum nicht ? weil svn dann automatisch sehr angenehm die Dateien aus den tiefen, tiefen, finsteren Unterverzeichnissen hinzufuegen würde aber eben auch die Ordner, die man nicht hinzufuegen will. Dagegen hilft kein svn:ignore weil svn add --force die ignores einfach ignoriert (Wie lustig oder eben auch gar nicht lustig sondern doof !)

Man muss svn:ignore hinzufuegen, wodurch svn status gefiltert wird. Dann muss man sich ein Skript schreiben, dass svn status ausführt und alle Dateien mit ? selbstständig added.

Mit dem Sopra SVN Server arbeiten
Auschecken
  1. Wo soll das working copy erstellt werden ?
    2. /home/bischowg/Sopra

  2. Das Verzeichnis selbst /home/bischowg/Sopra erstellen

  3. Konsole öffnen

  4. Nachsehen, was auf dem Server vorhanden ist
    5. svn list --verbose http://svn.mayastudios.de/sopra/repos/docu
    um das docu repository anzusehen 
    svn list --verbose http://svn.mayastudios.de/sopra/repos/sources
    um das sources repository anzusehen.

  5. das docs Verzeichnis nach /home/bischowg/sopra auschecken
    6. svn --username username checkout http://svn.mayastudios.de/sopra/repos/docu /home/bischowg/Sopra/docu
    Man muss den Pfad /home/bischowg/Sopra/docu nennen, da SVN beim Auschecken eines Ordners (hier: docu) den Inhalt dieses Ordners am angegebenen Pfad ablegt und nicht den Ordners selbst mit seinem Inhalt darin am angegebenen Pfad ablegt. SVN führt praktisch eine Kopie des Inhalts vom angegebenen Ordner im Repository in den Inhalt des angegebenen Ordner im working copy durch. Im obigen Fall wird also der Inhalt von docu in docu kopiert. Ganz einfach eigentlich. Hätte man den Pfad nur /home/bischow/Sopra genannt, so hätte man den Inhalt dieses Ornders im Sopra Ordner herumfahren, das wollen wir aber nicht. Der Inhalt soll auch wieder in den Ordner docu.
Die Stundenzetteldatei bearbeiten und ins Repository einchecken
  1. update - Gibt es seit dem letzten checkout Änderungen?
    2. svn update /home/bischowg/Sopra/docu

  2. Die Stundenzettel Datei bearbeiten

  3. status - den Änderungstatus der Stundenzetteldatei abfragen
    4. svn status /home/bischowg/Sopra/docu
    oder 
    svn status --verbose /home/bischowg/Sopra/docu
    Der Buchstabe M steht übrigens für modified.

  4. commit - Die Änderungen ins Repository hochladen
    5. svn commit /home/bischowg/Sopra/docu -m "Stunden eingetragen"
add - Dateien hinzufügen
add - Einen neuen Ordner im Repository anlegen
  1. ACHTUNG: Niemals die Qualitätskontrolle vergessen !
    2. Sie dürfen nie vergessen, das Sebastian die Qualitätskontrolle übernommen hat und er der einzige ist, der in das docu Repository commiten darf ! Wenn Sie Änderungen am docu Repository vornehmen, wird ihnen das verboten und der SVN Befehl schlägt mit einer Fehlermeldung fehl.

  2. Erstellen Sie den neuen Ordner in ihrem working copy
    3. Bsp.: 
    mkdir /home/bischowg/Sopra/sources/workplace/wb/test

  3. Stellen Sie den Ordner unter die Versionsverwaltung von SVN mit dem add Befehl
    4. svn add /home/bischowg/Sopra/sources/workplace/wb/test
    Alle Dateien, die in diesem Ordner liegen, werden auch geadded.

  4. Schicken Sie den Ordner ins Repository
    5. svn commit /home/bischowg/Sopra/sources -m "Ordner erstellt"

Branching

 Ein Branch hat den Ursprung in einem Dokument, das weiterhin besteht und weiterentwickelt wird. Der Branch wird parallel auch weiterentwickelt. Branches enstehen aus besonderen Wünschen eines neue hinzukommenden Interresenten, an das ursprüngliche Dokument, wobei das ursprüngliche Dokument jedoch ohne diese besonderen Änderungen weiter für den ursprünglichen Interressenten des Dokuments bestehen bleiben muss. Wir nennen das ursprüngliche Dokument der Einfachheit halber auch einfach branch. Damit gibt es nun Änderungen, die nur einem Dokument, also nur einem branch, zugute kommen sollen und im anderen Branch nicht auftauchen sollen. Des weiteren gibt es aber auch Änderungen, die sowohl im einen als auch im anderen Branch nötig sind, z.B. Schreibfehler. Daher besitzt SVN die Fähigkeit Änderungen spezifisch auszuwählen und in einen anderen Branch zu übernehmen. Dadurch kann man die Besonderheiten eines Branches wahren und von den Verbesserungen der Mitarbeiter an den anderen Branches profitieren, die man auch im eigenen Branch verwendnen kann.

Frequently Asked Questions

Wie kann ich den Inhalt eines Repository anzeigen lassen ?

 Man wendet den Befehl svn list an. Optional kann man sich ein langes listing mit dem Schalte --verbose oder -v anzeigen lassen. Nicht vergessen: Man kann nur über URLs auf Repositorys zugreifen. file:///pfad/zum/repository ist also nicht optional ! 
svn list --verbose file:///home/bischowg/svnrepository
Wenn Informationen über ein Unterverzeichnis haben möchte, so gibt man dieses Verzeichnis einfach mit der URL des svn list Befehls an.

Wie kann ich die Revision der Verzeichnisse und Dateien in meinem working copy anzeigen lassen ?

 Navigieren Sie in ihr working copy und führen Sie dort den Befehl svn log aus.

Was passiert falls ich lokal eine Datei verändert aber noch nicht commited habe und diese Datei aber im Repository zwischenzeitlich auch verändert worden ist ? Gehen meine Änderungen bei einem Update verloren ?

 Die Änderungen gehen nicht verloren, in keinem der folgenden Fälle:
  1. Falls die Änderungen nicht mit den eigenen Änderungen überschneiden oder komplett identisch sind, so wird ein merge durchgeführt und die Änderungen aus dem Repository werden mit der Datei im working copy verschmolzen. Beim Update wird der Statuscode G angezeigt. (G steht für das g in merge)
  2. Falls die Änderungen mit den eigenen Änderungen überschneiden und nicht identisch sind, so wird folgendes passieren: Beim update wird dann ein C (für conflict) angezeigt. Bevor man die eigenen Änderungen commiten kann, muss man den conflict manuel auflösen. Falls es sich bei der Datei die einen Konflikt verursacht um einen mime-type handelt, der mit einem Texteditor betrachtet werden kann, so wird svn mehrere Dinge tun. Es wird die Datei im administrativen .svn Verzeichnis als konfliktbehaftet markieren. Es wird die eigenen Änderungen und die Änderung aus dem Repository in den Text mit speziellen optisch hervorstechenden Zeilen umschlossen einfügen. Es wird drei zusätzliche Dateien ins working copy ablegen. Alle neuen Dateien heißen gleich wie die ursprüngliche Datei haben aber besondere Endungen. Die erste Datei erhällt die Endung .mine. Sie ist eine Kopie der Datei und enthällt daher die eigenen Änderungen. Die zweite Datei erhällt eine Endung die der Revision der Datei entspricht, bevor man die eigenen Änderungen an ihr vorgenommen hat. Die letzte Datei erhällt als Endung die Revisionsnummer der Datei die aus dem Repository kam und den Konflikt verursacht hat. Man kann nun folgendes tun. 1. Man schmeist die Änderungen weg und übernimmt einfach die Datei aus dem repository indem man die Endung mit der Revision wegnimmt und die Datei neu bennent. Danach muss man svn resolved aufrufen, damit SVN die .svn Ordner anpasst und die Datei als nicht konflikt behaftet markiert. svn resolved löscht dabei auch automatisch die drei neuen Dateien aus dem working copy. 2. man passt die Änderungen aus dem Repository mit den eigenen Änderungen an so das beide Programmierer glücklich sind und ruft svn resolved auf. 3. Man verwendet die alte Datei mit der Revisionsnummer der Revision bevor die Änderungen vorgenommen wurden und ruft dann svn resolved auf. Erst jetzt kann man einen Commit durchführen. Es ist dabei zu beachten das die konfliktbefreite Datei immer noch an der gleichen Stelle Änderungen enhällt, die mit den Änderungen aus dem Repsitory in Konflikt stehen (Es sei den man hat die Datei aus dem Repository übernommen) durch den Aufruf von svn resolve jedoch wird SVN gesagt, das diese Datei nun ohne Rücksicht auf Verluste ins Repository übernommen werden soll. Es ist daher einem Programmierer möglich die Änderungen seiner Teammitglieder zu überschreiben indem er einfach seine eigene Datei als konfliktfrei markiert indem er svn resolved für die Datei aufruft und dann einen commit durchführt ohne vorher die Änderungen seiner Teammitglieder zu übernehmen ! Wäre dies jedoch nicht möglich, so könnten niemals Änderungen zweier Programmierer an der gleichen Datei und innerhalb dieser Daeti an der gleichen Stelle erfolgen, da der Programmierer, der seine Änderungen später als der erste Programmiere commitet dann immer in die Röhre schaut und seine Änderungen nicht abschicken darf, da nur die Version aus dem Repository nicht mit der Version aus dem Repository in Konflikt steht !

Ich habe eine Datei ohne einen svn Befehl aus meinem working copy gelöscht. Wie passe ich die Struktur des working copy und des Repositorys jetzt so an, das die Datei auch aus den administrativen .svn Ordnern dieser beiden Orte verschwindet ?

 Man muss svn mitteilen, das die Datei bei einem erneuten aupdate nicht mehr aus dem Repository in das working copy übertragen werden soll, mit anderen Worten, das die Datei aus der, durch das Löschen enstehenden, nächsten Revision entfernt werden soll. Dazu verwendet man den Befehl svn delete und gibt als Parameter der Namen der Datei an die gelöscht werden soll. Nach einem update oder commit werden die Änderungen ins Repository übernommen. In älteren Revisionen ist die Datei allerdings noch enthalten.

Ich möchte ein update meines working copy durchführen und erhalte den Fehler svn: Failed to add directory 'docu/Entwurf': object of the same name already exists

 Der Grund ist, das der add Befehl auf dieses Verzeichnis ausgeführt wurde, das Verzeichnis aber bereits im Repository vorhanden ist. Wenn nun update durchgeführt wird, versucht svn den Ordner ins repository hinzuzufügen und danach neue Dateien vom repository herunterzuladen. Dabei kommt es zum beschriebenen Konflikt. Mit dem revert Befehl kann man den add Befehl rückgängig machen. 
svn revert /docu/Entwurf
SVN versucht nun nicht mehr den add Befehl auszuführen, dieser Auftrag wurde durch revert gelöscht. Nun funktioniert das update des docu Verzeichnisses wieder.

Wie kann ich herausfinden, welche Dateien in meinem working copy noch nicht mit svn add geadded wurden ?

 Führen Sie den Befehl svn status fuer das entsprechende Verzeichnis aus. svn status schreibt ein Fragezeichen vor jede Datei, die noch nicht geadded wurde, die also noch nicht unter Versionskontrolle steht.

Wie kann ich mit svn bestimmte Dateien und Ordner ignorieren, so das sie bei einem add oder commit nicht mit ins Repository übertragen werden ?

 Das funktioniert mit den sogenannten Properties von SVN. (Lesen Sie dazu im svn-book.pdf auf Seite 151 bzw. auf der Seite 134 im Dokument selbst). Es gibt das svn:ignore Property, das auf Verzeichnisse (vielleicht auch auf Dateien ???)angewendet werden kann. Das svn:ignore Property ist eine Liste von Schemas. Bei einem recursiven add Befehl, werden innerhalb eines Verzeichnisses V alle Dateien und Ordner nicht geadded, die mindestens einem Schema in der svn:ignore Property des Verzeichnisses V entsprechen. Des weiteren zeigt eine svn status Befehl alle Dateien und Ordner nicht an, die mindestens einem Schema in der svn:ignore Property des Verzeichnisses V genuegen. Mit dem switch --no-ignore kann man den svn status Befehl sagen, das er trotzdem alle Dateien und Ordner anzeigen soll, auch die die ignoriert werden. 
svn status --no-ignore
Das Vorgehen ist das Folgende. Angenommen in Ihrem working copy gibt es das Verzeichnis V. Darin liegt die Datei test.java, die Sie ignorieren möchten. Des weitern liegen dort mehrere Dateien mit der Endung .ccf die Sie allesamt auch ignorieren wollen. Dann setzen Sie das svn:ignore Property des Verzeichnisses V wie folgt: 
svn propedit svn:ignore V
propedit ist ruft den Standardeditor (bei mir vi) auf, und sie können Ignorier-Schemas für das svn:ignore Property eingeben. Ein Schema wird pro Zeile eingetragen. Sie tragen, um die Datei test.java und alle .ccf-Dateien zu ignorieren folgendes ein: 
test.java
*.ccf

Wie kann ich mit svn einen Ordner und alle Unterordner unter Versionskontrolle stellen ?

 svn add arbeitet standardmäßig rekursiv. (es gibt einen switch, der svn add auf nicht rekursiv einstellt !). Das Problem ist nur, das svn add Ordner, die bereits unter Versionskontrolle stehen überspringt und nicht in solche Ordner hinabsteigt. Wenn man also neue Dateien in Ordnern erzeugt hat, die bereits unter Versionskontrolle stehen, und man möchte in diesen Ordner alle Dateien adden, dann muss man SVN dazu zwingen in bereits versionierte Ordner rekursiv abzusteigen. Dazu verwenden man den switch --force des svn add Befehls. 
svn add sources --force
SVN rekursiert nun über alle Ordner und fügt alle Dateien und Ordner hinzu, die noch nicht unter Versionskontrolle stehen.

ACHTUNG: Es werden nun wirklich alle Dateien und Ordner hinzugefügt. Womöglich möchten Sie das SVN unwichtige Dateien und Ordner ignoriert. Lernen Sie dazu wie man Dateien und Ordner mit SVN ignoriert.

ACHTUNG: Ich habe herausgefunden, das der svn add --force Befehl leider auch Ordner und Dateien hinzufügt, die durch das svn:ignore Pattern ignoriert werden sollten.

Wie kann ich mit svn eine Binärdatei unter Versionskontrolle stellen, so dass svn bei einem update keine Unterscheidungen in die Datei hineinschreibt ?

 Dazu gibt es die Property svn:mime-type. Man muss der entsprechenden Datei einen mime-type geben, der keinem Textdateiformat entspricht. Bei einem update, wird die lokale Nicht-Text-mime-datei die im lokalen working copy vorlag, mit der Änderunge .orig versehen. Aus dem Repository wird die mime-Datei mit den Änderungen unter ihrem normalen Namen ins Repository gelegt.

Herausfinden in welchen Bereichen des Repository man schreiben darf

SVN Server einrichten unter DSL
Standalone server option
Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x). The standalone server can run as an inetd service, or in daemon mode, and offers basic authentication and authorization. It can also be tunnelled over ssh. Wir werden svn als custom Server installieren.
Download
Download the Subversion 1.3.2 sourcecode from the svn homepage.
Transfer to the DSL PC via scp
scp subversion-1.3.2.tar.gz root@192.168.0.101:/root/download/subversion-1.3.2.tar.gz
Das Verzeichnis /root/download muss bereits existieren.
tar.gz auf dem DSL PC entpacken
tar xvfz subversion-1.3.2.tar.gz -C /root/temp
Das Verzeichnis /root/temp muss existieren.
Der erste Übersetzungsversuch
Rufen Sie in dem Ordner, in dem sich die svn Quellen befinden, das configure Skript auf. configure probiert eine makefile mit allen Informationen, die es aus ihrem System ausliest, zu bauen. Immer wenn es einen Mangel an Software feststellt, wird dieser mitgeteilt. Damit ist die Software installationsfähig, wenn configure komplett durchläuft und configure kann als Indikator für fehlende Software verwendet werden, falls svn nicht problemlos durchläuft. 
configure
Das Ergebnis war abzusehen. configure bricht mit folgender Fehlermeldung ab. 
configure: error: no acceptable C compiler found in $PATH
Man muss also einen Compiler installieren.





zum Seitenanfang
zur Hauptseite

Letzte Änderung: 09.11.2005