Getting Started/Sources/Subversion (de)
Getting Started/Sources/Using Subversion with KDE
Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文
Anleitungsserie | Anfang |
Voriges Kapitel | None |
Nächstes Kapitel | n/a |
Weiterführende Texte | n/a |
Navigation | Deutsche Startseite |
Zusammenfassung
Der folgende Text ist eine schnelle kde-spezifische Einführung, wie man Subversion benutzt, um auf Dateien und Software im KDE Repository zuzugreifen. Für einen vollständigen Überblick über die Fähigkeiten von Subversion verweisen wir auf das Buch "Version Control with Subversion (englisch)".
Am Anfang
Um das KDE Subversion Repository benutzen zu können, benötigen Sie zwei Dinge:
- Ein Subversion Client Programm
- Einen Zugang zu unserem Repository
Beachte: Für einen anonymen nur-lesen Zugriff benutzen Sie das Protokoll "svn", kein "yourname@" den Server "anonsvn.kde.org" statt dem unten genannten.
Subversion installieren: Eine Anleitung zur Installtion des Client Programms wird hier nicht gegeben. Sehen Sie in den Installtionsanleitungen Ihres Systems nach, um herauszufinden, wie man Subversion installiert. Sie benötigen mindesten Version 1.1. Wenn Sie Subversion selber compilieren und Sie auf das Repository per https (und nicht über svn+ssh) zugreifen wollen, benötigen Sie SSL und ZLIB Unterstützung und müssen daher die --with-ssl --with-zlib Option übergeben.
Alternativ können Sie auch einen der zahlreich vefügbaren graphischen Clients installieren. Diese Anleitung wendet sich an personen, die nur das svn Programm benutzen und bezieht sich dabei auf Dinge die mit dem alten cvs Programm erledigt wurden.
Ein Benutzerkonto bekommen: Hatten Sie vorher ein CVS Benutzerkonto, wurde dieses zum neuen Subversion Client migriert. Wenn nicht, sehen Sie in der entsprechenden Anleitung nach, wie man eines bekommt.
Die Struktur des KDE Repository
svn.kde.org/home/kde
ist die Adresse des KDE Subversion Repositorys. Das Repository wird über das HTTPS oder SVN-SSH Protokoll angesrochen, was bedeutet, dass Ihr Passwort sicher gegenüber Abhörversuche dritter ist.
Der SSL certificate md5 fingerprint für die Repositorys ist:
F6BF EDE2 D016 D1B2 4F18 742E 2C8F B7EF
Der SSL certificate sha1 fingerprint für die Repositorys ist:
e1:e6:41:96:3c:eb:ae:78:e2:73:0d:a2:32:2f:6b:21:13:bf:3d:0f
Für Personen, die svn+ssh benutzen ist hier der Fingerprint des RSA Schlüssels des Servers:
86:f3:66:06:20:74:81:d0:1b:b4:2f:25:03:f7:8e:fb
Das Repository ist in Hauptverzeichnisse organisiert:
- /branches
- /tags
- /trunk
Man kann das Repository durchforgsten über http://websvn.kde.org/
Das Unterverzeichnis /trunk
Das /trunk Hauptunterverzeichnis ist dasjenige, in dem die Hauptentwicklung an KDE stattfindet. Was Sie hier finden, wird als nächstes als KDE und assoziierte Programme veröffentlicht. Hier finden Sie auch das www Modul, welches die Webpages rund um KDE beinhaltet.
/trunk ist unterteilt in folgende Unterverzeichnisse:
- KDE/
KDE selber, welches die nächste Veröffentlichung werden wird. Es besteht aus folgenden Modulen:- kdelibs - KDE Hauptbibliotheken, die von allen KDE Programmen benutzt werden
- kdebase - KDE Basisprogramme, wie das KDE Control Center, Plasma (die Oberfläche) und Konqueror (der Web Browser)
- kdeaccessibility - Accessibility Dateien
- kdeadmin - KDE Administrationsprogramme
- kdeartwork - Bilder, Themen, Sounds und andere künstlerische Dateien
- kdebindings - Bindungen für andere Sprache außer C++
- kdeedu - Erzieherische und Wissenschaftliche Programme für KDE
- kdegames - KDE Spiele
- kdegraphics - KDE Graphikapplicationen
- kdemultimedia - KDE Multimediaapplicationen
- kdenetwork - KDE Netzwerkapplicationen
- kdepim - KDE Personal Information Management Applicationen
- kdepimlibs - Biblotheken, die von KDE-PIM Applicationen benötigt werden.
- kdesdk - KDE Software Development Kit Applicationen
- kdetoys - KDE Spielzeug Applicationen
- kdeutils - Allgemeine KDE Werkzeuge
- kdevelop - Das KDevelop Programm
- kdevplatform - Die Entwicklerplatform auf der KDevelop basiert
- kdewebdev - Eine KDE Webentwicklungsapplikation
- kde-common
- Allgemeines admin/ Verzeichnis
- bugs/
- Bugzilla Dateien
- developer.kde.org/
- Der Inhalt von developer.kde.org
- extragear/
- KDE Programme die sich außerhalb der Haupt KDE Veröffentlichungen aufhalten
- kdereview/
- Vorübergehende Heimat für all die KDE Applikationen, von denen geglaubt wird, daß sie reif für eine Veröffentlichung sind. Von hier aus werden die Applikationen entweder nach /trunk/KDE/ oder nach /trunk/extragear/ verschoben, sobald die größten Probleme ausgeräumt sind.
- kdesupport/
- Unterstützende Programme und Bibliotheken für KDE
- koffice/
Das KDE Office Paket, welches folgende Programme beinhaltet:- karbon
- kchart
- kexi
- kformula
- kivio
- koshell
- kplato
- kpresenter
- krita
- kspread
- kugar
- kword
- konstruct/
- Konstruct, das KDE build Programm
- l10n-kde3/
- Übersetzungen für die "unstabilen" Module von KDE 3 (extragear, playground)
- l10n-kde4/
- Übersetzungen für KDE 4
- playground/
- Der KDE Spielplatz: Applications die gerade entwickelt werden aber noch keine Veröffentlichungsqualität erreicht haben.
- qt-copy/
- Zu Vereinfachung eine Kopie von Trolltechs Qt Bibliothek, auf welcher KDE basiert.
- tests/
- khtml, KOffice und ksvg Testfälle
- valgrind/
- Die Valgrind Application, welche im KDE Repository betreut wird jedoch kein Teil von KDE selber ist. Neuere Versionen von Valgrind werden in einem eigenen Repository entwickelt. Das KDE Valgrind Modul beinhaltet nur Valgrind bis zur Version 2.4.
- www/
- Webpages für die KDE Site (und verwandte Sites). Schreibzugriff auf dieses Verzeichnis ist beschränkt.
Das Unterverzeichnis /tags
Dieses Verzeichnis beinhaltet die offiziellen Veröffentlichung von den Programmen die im KDE Repository verwaltet und entwickelt werden. Jede einzelne Applikation hat hier ein Unterverzeichnis, innerhalb von diesem finden Sie die Release-Nummern.
So kann zum Beispiel der Code für KDE 3.4.0 unter /tags/KDE/3.4.0/ gefunden werden.
Das Unterverzeichnis /branches
Dieses Verzeichnis beinhaltet die Zweig-versionen von Applikationen nach einer Hauptveröffentlichung.
Die meisten KDE Applikationen halten sich an die Philosophie, dass neue Features (ebenso wie neue Zeichneketten für den Benutzer) erst im nächsten Veröffentlichungszyklus — derjenige der in /trunkg/ entwickelt wird — einfließen. Fehlerbereinigungen werden jedoch auf alle Applikationen angewandt, auch nach einer Veröffentlichung.
Um das zu bewerkstelligen, wird ein Zwei in dem Moment der Veröffentlichung erzeugt und zeigt damit den Status dieser Dateien zu diesem Zeitpunkt an. Fehlerbereinigungn werden dann in diese Dateien eingepflegt. Diese Zweige sind dann diejenigen die unter /branches/ zu finden sind.
So kann zum Beispiel der KDE 3.4.x Zweig unter /branches/KDE/3.4/ gefunden werden.
Die Unterverzeichnisse die Sie in /branches finden, sie die Unterverzeichnisse der Aplikationen wie akregator/, amarok/, arts/, k3b/, etc. Sie finden hier auch ein KDE/ Unterverzeichnis, welches die offiziellen KDE Veröffentlichung beinhalten.
Es gibt ein spezielles Unterverzeichnis in /branches namens work/. Dieses Unterverzeichnis wird als "Arbeitszweig" berzeichnet und beinhaltet Zweige bei denen an neuen Features gearbeitet wird. Manchmal sind diese sehr experimentell. Arbeitszweige für mehrere Applikationen finden sich in /branches/work/, doch für einzelne Applikationen finden sich Arbeitszweige im jeweiligen Unterverzeichnis. Diese Entscheidung liegt bei den Entwicklern.
Auschecken und Aktualisieren
Auschecken
Um entwas aus Subversion auszuchecken benutzt man das Unterkommando checkout:
WARNUNG: Wenn Sie trunk/KDE oder branches/KDE/foo auschecken werden Sie auch die komplette kde-i18n herunterladen!
Angenommen Sie wollen nur KDevelop aus dem KDE Repository auschecken, würden Sie folgende Kommandos eingeben:
CVS Kommando:
cvs -d :pserver:[email protected]:/home/kde login cvs -d :pserver:[email protected]:/home/kde checkout kdevelop
Subversion Kommando:
CVS Benutzer die einen ssh Zugang besitzen, sollten das Protokoll svn+ssh, CVS Benutzer, die einen Passwortzugang benutzen sollten das Protokoll https im folgenden benutzen.
svn checkout <protocol>://<username>@svn.kde.org/home/kde/trunk/KDE/kdevelop
Aktualisieren
Um zu aktualisieren, benutzen Sie das update Unterkommando.
Hier gibt es keinen Unterschied zu CVS: Sie wechseln in ihre ausgecheckte lokale Kopie (für diejenigen, für die das alles neu ist: die ausgecheckte Kopie sollte sich in Ihrem Heimatordner befinden) und geben ein svn update Kommando (oder kürzer svn up).
Den Status einer Datei ermitteln
Um herauszufinden welche lokalen Dateien verändert wurden, haben die meisten unter CVS das Kommando cvs up aufgerufen und dann diejenigen Dateien gesucht, die mit einem M markiert waren. Das funktioniert unter svn nicht, daher müssen Sie das Kommando svn status aufrufen, um den Status der Dateien zu ermitteln.
Ins Repository hochladen
Um Änderungen hochzuladen ruft man, ähnlich wie bei CVS, die Unterkommandos commit oder checkin (Kurzversion davon ci) auf.
CVS Kommando:
cvs commit # oder cvs ci # oder cvs ci filename.cpp
Subversion Kommando:
svn commit # oder svn ci # oder svn ci filename.cpp
Auf diese Weise wird svn den in $SVN_EDITOR eingetragenen Texteditor aufrufen, damit Sie das Änderungsprotokoll ausfüllen können. Wenn Sie es vorziehen, können Sie svn auch über die -m Option eine vollständige Mitteilung übergeben:
svn ci -m "Updating protocol to conform to HTTP/1.1"
Dateien ignorieren
Subversion speichert die zu ignorierenden Dateien für jedes Verzeichnis. Um diese Liste für das aktuelle Verzeichnis zu bearbeiten, rufen Sie einfach
svn propedit svn:ignore .
auf. Damit wird der eingestellte Editor aufgerufen, in dem Sie die Namen der Dateien eintragen können, die ignoriert werden sollen, eine Datei pro Zeile. Wenn Sie fertig sind, einfach ein commit ausführen, damit die Dateien auf dem Server aktualisiert werden.
Eine Menge Dateien wurden bei CVS mit Hilfe der globalen Ignorierliste ignoriert, diese Liste wird von SVN nicht unterstützt. Sie können auf svn 1.3 warten oder Sie müssen die Ignorierliste in die Sammelgruppe in ihrer ~/.subversion/config einfügen (alle in einer Zeile):
global-ignores = *.o *.lo *.la .*.rej *.rej .*~ *~ .#* #*# .DS_Store *.moc *.moc.cc *.moc.cpp config.log config.status config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure *_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp *.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp *_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl
Working with multiple revisions and branches
Unlike CVS, Subversion doesn't generate a revision number for each file modified. Instead, the full repository is versioned, as a whole. This way, a given revision number represents the state the repository was on a given date. In other words, a revision number is like a timestamp (in fact, the Subversion server uses this fact to search for dates in the repository faster).
So, for instance, when you check out the KDE repository, Subversion will tell you the following:
Updated to revision 403821.
This means that the latest revision available at the time of the operation was 403821. If you make a modification and commit, Subversion will update the server-side revision and will inform you of it. Like CVS, only the committed files will be updated: you will need run cvs up to update the rest of the files.
If you want to retrieve a specific revision of a file, you can use the -r switch. Besides the revision number itself, -r accepts a number of other possibilities:
- The revision number: for example, use -r 403819 to retrieve that version
- BASE: the revision you updated to
- COMMITTED: the revision a file was last modified, before BASE
- PREV: the revision of the previous commit to the file before COMMITTED
- HEAD: the most recent revision available in the server
- { date }: between curly brackets, you can specify a date for searching the closest revisions
The following illustrates the evolution of the keywords:
- You run svn up to update to the latest available revision. Suppose Subversion tells you it updated to revision 403821. This means that HEAD and BASE are 403821.
- You modify file README and commit it. Suppose Subversion tells you it committed revision 403822. This means HEAD, BASE and COMMITTED are 403822.
- You modify the file again and commit it. Now PREV is 403822, but HEAD, BASE and COMMITTED are updated to a new value (suppose it's 403823).
- Now someone else modifies the repository, and you update your working copy. If Subversion tells you it updated to 403824, this means now HEAD and BASE are moved to 403824 (but PREV and COMMITTED stay the same)
- If someone modifies the README file now, HEAD is moved. The other keywords stay the same for you, until you update. At this time, we will have HEAD = 403825 (the latest available revision), BASE = 403824 (the revision you last updated to), COMMITTED = 403823 (the revision of the latest change to the file when you last updated) and PREV = 403822 (the revision of the change before COMMITTED)
Those keywords are useful to retrieve logs and diffs for commits to the repository.
If you want to see the difference between your working copy and BASE, you can run:
svn diff
This is a very fast operation, since Subversion keeps a local copy of BASE. It doesn't need a network connection to accomplish this operation.
If you want to see the difference between your local copy and the latest available on the server, you will run:
svn diff -r HEAD
If you want to see what has changed in the repository since you've last updated, you can use:
svn diff -r BASE:HEAD
If you want to see the last change to a file before BASE, you can use:
svn diff -r PREV:BASE # or svn diff -r PREV:COMMITTED
That is also valid for the svn log command.
Unterverzeichnisse von anderen Orten verlinken
It can happen you would like to include a copy of a subdirectory from another place, but just for convenience, not for developing the code in there. Of course it should be updated automatically whenever the original changes. Subversion can help you. You need to edit the property svn:external of the directory the subdirectory should be added to. So for the current directory you use
svn propedit svn:externals .
and then enter lines of the form
libkhalkhi svn://anonsvn.kde.org/home/kde/trunk/playground/pim/khalkhi
Updating will now fetch /trunk/playground/pim/khalkhi into the subdirectoy libkhalkhi.
You use svn://anonsvn.kde.org and not another protocol, because anonsvn.kde.org is accessible to everyone. Using https: or svn+ssh: would only work for users of that protocol. There are still some small disadvantage with anonsvn.kde.org: It is not always in synchronization with svn.kde.org, so updates in the original branch may take a while to appear on anonsvn.kde.org. And some strict firewalls are blocking the svn: protocol.
A special case in KDE 3 is the subdirectory admin, containing the KDE 3 build utilities. It is linked in to the top directory in all modules, and maintained in /branches/KDE/3.5/kde-common. For admin the KDE subversion server is configured to allow readonly access for everyone, so if you see
admin https://svn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
there is no need to change this.
Mehr Informationen im KDE Wiki
Siehe auch the KDE wiki für mehr Informationen über Subversion in KDE