SVN: Unterschied zwischen den Versionen
Flo (Diskussion | Beiträge) K (→DGL-Repositories: Benutzernamen hervorgehoben! (wurde schon von 2 Leuten uebersehen)) |
K |
||
| (14 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
| Zeile 2: | Zeile 2: | ||
= Allgemein = | = Allgemein = | ||
| − | SVN steht für Subversion und ist eine Version Control Software. Subversion ist vergleichbar mit dem bekannteren CVS und versucht zahlreiche Schwachstellen dieses Systems zu verbessern. Es ist davon auszugehen, dass SVN in den nächsten Jahren CVS als Version Control Software ablösen wird. So wechselte z.b. [http://www.kde.org www.kde.org] Anfang des Jahres zu SVN. Oftmals wird diese Art von Software direkt mit OpenSource in Verbindung gebracht, was vermutlich allerdings mehr situationsbedingt ist. So bietet Microsoft für den kommerziellen Bereich SourceSafe an. Subversion ist im Gegensatz dazu allerdings frei - sowohl der Source Code als auch von kostentechnischer Betrachtung her. | + | '''SVN''' steht für Subversion und ist eine Version Control Software. Subversion ist vergleichbar mit dem bekannteren CVS und versucht zahlreiche Schwachstellen dieses Systems zu verbessern. Es ist davon auszugehen, dass SVN in den nächsten Jahren CVS als Version Control Software ablösen wird. So wechselte z.b. [http://www.kde.org www.kde.org] Anfang des Jahres 2005 zu SVN. Oftmals wird diese Art von Software direkt mit OpenSource in Verbindung gebracht, was vermutlich allerdings mehr situationsbedingt ist. So bietet Microsoft für den kommerziellen Bereich SourceSafe an. Subversion ist im Gegensatz dazu allerdings frei - sowohl der Source Code als auch von kostentechnischer Betrachtung her. |
= Einsatzbereich = | = Einsatzbereich = | ||
| − | Wieso wird Versionierungssoftware gerade im OpenSource-Bereich häufig eingesetzt? Der Grund dafür ist denkbar einfach. Zahlreiche Entwickler werkeln am gleichen Source Code herum. Jeder der einmal versucht hat an einem Source Code mit drei Leuten über eine Netzwerkfreigabe zu arbeiten, wird es bei diesem ersten Versuch belassen haben. Während man selbst eine Änderung an einer Datei durchgeführt hat, hat ein anderer in der gleichen Datei bereits Änderungen durchgeführt. Derjenige der zuletzt sichert... gewinnt. ;) | + | Wieso wird Versionierungssoftware gerade im OpenSource-Bereich häufig eingesetzt? Der Grund dafür ist denkbar einfach. Zahlreiche Entwickler werkeln am gleichen Source Code herum. Jeder, der einmal versucht hat, an einem Source Code mit drei Leuten über eine Netzwerkfreigabe zu arbeiten, wird es bei diesem ersten Versuch belassen haben. Während man selbst eine Änderung an einer Datei durchgeführt hat, hat ein anderer in der gleichen Datei bereits Änderungen durchgeführt. Derjenige der zuletzt sichert... gewinnt. ;) |
| − | Ein Lösungansatz könnte | + | Ein Lösungansatz könnte so aussehen, dass eine Person die Daten entgegennimmt und diese dann zusammen an einen Ort zusammenfügt. Ein Projekt wie KDE würde jedoch bei mehreren hunderten Entwicklern bereits innerhalb weniger Tage ins absolute Chaos stürzen. Aus diesem Grund wurden Versionierungssoftware entwickelt. Stellvertretend für diese Person nimmt der SVN-Server Veränderungen entgegen und speichert diese zentral ins Repository. Zwar verhindert dies nicht, dass zwei Personen am gleichen Code arbeiten, allerdings ist ein Datenverlust ausgeschlossen, da jederzeit eine ältere Revision angesehen werden kann. Zudem ist SVN sogar begrenzt in der Lage, den Source Code aus zwei veränderten Versionen wieder zu einem zusammenzusetzen. |
| − | Doch auch ein einzelner Entwickler kann Vorteile beim Einsatz von Subversion erlangen. Wer bereits einmal an einem großen Projekt gearbeitet hat, wird es vielleicht nur zu gut kennen. Ein Modul wird codiert und das Dummy fliegt raus. Damit alles | + | Doch auch ein einzelner Entwickler kann Vorteile beim Einsatz von Subversion erlangen. Wer bereits einmal an einem großen Projekt gearbeitet hat, wird es vielleicht nur zu gut kennen. Ein Modul wird codiert und das Dummy fliegt raus. Damit alles zusammenpaßt, werden auch kleinere Änderungen an anderen Modulen vorgenommen - doch am Ende läuft ein Modul nicht mehr. Vor den Änderungen war dies allerdings noch intakt. Ohne Versionierungssoftware schaut man dann in die Röhre oder muss sich seines Hirnes bedienen. Wurde Subversion verwendet, wäre es möglich, eine ältere Revision zu laden und mit der aktuellen zu vergleichen. Der Fehler, der nun verhindert, dass das Modul läuft, sollte schnell gefunden sein. (Ansonsten sollte man seine Projektplanung dringend überdenken.) |
= Begriffe = | = Begriffe = | ||
| − | Ein '''Repository''' ist die Bezeichnung für ein SVN-Archiv. Innerhalb des Repository werden die einzelnen '''Revisionen''' verwaltet. Jedes Mal wenn jemand etwas in das Repository kopiert, erhält dieser Beitrag automatisch eine neue Revisionsnummer und kann | + | Ein '''Repository''' ist die Bezeichnung für ein SVN-Archiv. Innerhalb des Repository werden die einzelnen '''Revisionen''' verwaltet. Jedes Mal, wenn jemand etwas in das Repository kopiert, erhält dieser Beitrag automatisch eine neue Revisionsnummer und kann anhand dieser eindeutig identifiziert werden. Es ist jederzeit möglich, Source Code einer älteren Revision auszuchecken. |
| − | Um an einen Projekt zu arbeiten erfolgt zunächst ein '''Checkout'''. Hierbei wird eine Kopie des Repository auf den lokalen Rechner kopiert. Dieses steht automatisch unter Versionskontrolle und alle Änderungen daran werden automatisch erfaßt. Sind Änderungen fertig und lauffähig, macht der Programmierer ein '''Commit''' und überträgt seine Änderungen wieder an den Server. Der umgekehrte Weg nennt sich '''Update''' und gleicht die lokale Version mit der des Repository wieder ab. | + | Um an einen Projekt zu arbeiten, erfolgt zunächst ein '''Checkout'''. Hierbei wird eine Kopie des Repository auf den lokalen Rechner kopiert. Dieses steht automatisch unter Versionskontrolle und alle Änderungen daran werden automatisch erfaßt. Sind Änderungen fertig und lauffähig, macht der Programmierer ein '''Commit''' und überträgt seine Änderungen wieder an den Server. Der umgekehrte Weg nennt sich '''Update''' und gleicht die lokale Version mit der des Repository wieder ab. |
| − | Der Aufbau eines Repository ist meistens denkbar einfach. Ein sogenannter '''trunk''' (Stamm) stellt den Hauptentwicklungszweig dar. Hier fließen auch kritische Änderungen ein. Sobald ein Release bevor steht wird eine Kopie des trunks als '''branch''' (Zweig) erzeugt. Die Entwickler nehmen hier nur noch Bugfixes vor und versuchen Fehler zu beheben. Es werden keine neuen Funktionen eingebaut. Sind keine Fehler mehr vorhanden und die Software gereleast, wird ein '''tag''' angelegt. Es handelt sich hierbei um einen aktuellen Snapshoot des Source Codes. Natürlich unterscheidet sich die Art wie die einzelnen Projekte verwaltet wird. Bei dieser Konstellation handelt es sich jedoch um eines der häufigsten | + | Der Aufbau eines Repository ist meistens denkbar einfach. Ein sogenannter '''trunk''' (Stamm) stellt den Hauptentwicklungszweig dar. Hier fließen auch kritische Änderungen ein. Sobald ein Release bevor steht wird eine Kopie des trunks als '''branch''' (Zweig) erzeugt. Die Entwickler nehmen hier nur noch Bugfixes vor und versuchen Fehler zu beheben. Es werden keine neuen Funktionen eingebaut. Sind keine Fehler mehr vorhanden und die Software gereleast, wird ein '''tag''' angelegt. Es handelt sich hierbei um einen aktuellen Snapshoot des Source Codes. Natürlich unterscheidet sich die Art wie die einzelnen Projekte verwaltet wird. Bei dieser Konstellation handelt es sich jedoch um eines der häufigsten und ist z.B. beim KDE-Projekt anzufinden: [http://websvn.kde.org/ KDE WebSVN]. |
= Anleitung = | = Anleitung = | ||
| Zeile 22: | Zeile 22: | ||
== Windows == | == Windows == | ||
[[Bild:Tsvn_checkout.png|thumb|256px|left|TortoiseSVN wird im Explorer eingebettet]] | [[Bild:Tsvn_checkout.png|thumb|256px|left|TortoiseSVN wird im Explorer eingebettet]] | ||
| − | Die Verwendung von SVN ist unter Windows denkbar einfach. [http://tortoisesvn.tigris.org/ TortoiseSVN] bietet sich als grafischer Client an und wird direkt in den Windows-Explorer integriert. Wir spielen an dieser Stelle einmal durch, dass wir ein Checkout aus dem DGL-Test-Repository durchführen und eine neue Datei wieder zum Repository hinzufügen. Zunächst bewegen wir uns an die Stelle an der das Repository angelegt werden soll. Aus dem Kontextmenu des Explorer klicken wir auf '''SVN Checkout...'''. | + | Die Verwendung von SVN ist unter Windows denkbar einfach. [http://tortoisesvn.tigris.org/ TortoiseSVN] bietet sich als grafischer Client an und wird direkt in den Windows-Explorer integriert. Wir spielen an dieser Stelle einmal durch, dass wir ein Checkout aus dem DGL-Test-Repository durchführen und eine neue Datei wieder zum Repository hinzufügen. Zunächst bewegen wir uns an die Stelle, an der das Repository angelegt werden soll. Aus dem Kontextmenu des Explorer klicken wir auf '''SVN Checkout...'''. |
| − | Es öffnet sich ein neues Fenster in dem wir die Position des Repository angeben müssen. Dies kann entweder wie in diesem Beispiele eine ganze gewöhnliche URL sein oder auch ein Repository auf dem lokalen Rechner. Sollte das Zielverzeichnis nicht existieren werden wir automatisch gefragt, ob dieses angelegt werden soll. | + | Es öffnet sich ein neues Fenster, in dem wir die Position des Repository angeben müssen. Dies kann entweder wie in diesem Beispiele eine ganze gewöhnliche URL sein oder auch ein Repository auf dem lokalen Rechner. Sollte das Zielverzeichnis nicht existieren, werden wir automatisch gefragt, ob dieses angelegt werden soll. |
[[Bild:Tsvn_checkout2.png|thumb]] | [[Bild:Tsvn_checkout2.png|thumb]] | ||
| − | Aus Sicherheitsgründen sind die meisten Repository geschützt und man muss sich zunächst authentifizieren. Im Falle dieses Beispiels ist der Benutzername "public" und das Passwort leer. Sollte kein Fehler auftreten meldet der SVN-Client, welche Revision gerade ausgecheckt wurde. Im Explorer ist das Repository nun wie ein normaler Ordner zu sehen. Allerdings sollte neben diesem ein grüner Haken sein, der signalisiert, dass die lokale Kopie auf dem neusten Stand ist. Nun betreten wir die Kopie mit einem Doppelklick und erzeugen eine neue Datei namens "svntest.txt" | + | Aus Sicherheitsgründen sind die meisten Repository geschützt und man muss sich zunächst authentifizieren. Im Falle dieses Beispiels ist der Benutzername "public" und das Passwort leer. Sollte kein Fehler auftreten, meldet der SVN-Client, welche Revision gerade ausgecheckt wurde. Im Explorer ist das Repository nun wie ein normaler Ordner zu sehen. Allerdings sollte neben diesem ein grüner Haken sein, der signalisiert, dass die lokale Kopie auf dem neusten Stand ist. Nun betreten wir die Kopie mit einem Doppelklick und erzeugen darin eine neue Datei namens "svntest.txt". Dieses befindet sich nicht automatisch unter Versionskontrolle. Deswegen klicken wir diese mit der rechten Maustaste an und wählen aus dem Kontextmenu "Add" aus. Es erscheint ein neuer Dialog, in dem zusammengefaßt wird, welche Dateien unter Versionskontrolle gestellt werden soll. Beachtet bitte, dass dieser Vorgang nur bei neuen Dateien notwendig ist. Dateien, die bereits aus dem Repository bezogen werden, stehen automatisch unter Kontrolle. |
| − | [[Bild:Tsvn_symbols.png|thumb|128px|left|Grün bedeutet, dass unsere Kopie aktuell ist. Rot bedeutet, dass Änderungen noch nicht an den Server übertragen wurden.]] Nun wollen wir die Änderungen noch an den Server übertragen. Hierfür gehen wir ein Verzeichnis tiefer und klicken es mit der rechten Maustaste an. Hierbei nehmen wir zur Kenntnis, dass unsere Kopie statt einem grünen Haken ein rotes Ausrufezeichen hat. Es wurden Änderungen durchgeführt. Dort befindet sich u.a. "Update" mit dem Ihr Änderungen des Servers wieder zu Eurer Kopie hinzufügen könnt. Aus dem Kontextmenu wählen wir nun jedoch "Commit" aus um die Änderungen zum Server übertragen. Es erscheint ein neuer Dialog in dem | + | [[Bild:Tsvn_symbols.png|thumb|128px|left|Grün bedeutet, dass unsere Kopie aktuell ist. Rot bedeutet, dass Änderungen noch nicht an den Server übertragen wurden.]] Nun wollen wir die Änderungen noch an den Server übertragen. Hierfür gehen wir ein Verzeichnis tiefer und klicken es mit der rechten Maustaste an. Hierbei nehmen wir zur Kenntnis, dass unsere Kopie statt einem grünen Haken ein rotes Ausrufezeichen hat. Es wurden Änderungen durchgeführt. Dort befindet sich u.a. "Update" mit dem Ihr Änderungen des Servers wieder zu Eurer Kopie hinzufügen könnt. Aus dem Kontextmenu wählen wir nun jedoch "Commit" aus, um die Änderungen zum Server übertragen. Es erscheint ein neuer Dialog, in dem zusammengefaßt wird, welche Dateien hochgeladen werden sollen. Im oberen Memofeld solltet Ihr den Grund eintragen, damit die anderen Leute wissen, weswegen Ihr Änderungen durchgeführt habt. Beschränkt Euch dort bitte auf die wichtigsten Dinge. Logs wie "habe hinter dem A ein N gesetzt und dann in Zeile 20 aus der 7 eine 6 gemacht" helfen niemanden wirklich weiter. Nach der Bestätigung und Authentifizierung sollte die Benachrichtigung erscheinen, dass die Dateien auf dem Server eingetroffen sind. Es sollte eine neue Revisionnummer vergeben sein. |
Dies sollte als kleine Einleitung für SVN erst einmal reichen, auch wenn dies nur ein Kratzen an der Oberfläche war. | Dies sollte als kleine Einleitung für SVN erst einmal reichen, auch wenn dies nur ein Kratzen an der Oberfläche war. | ||
== Linux == | == Linux == | ||
| + | Die neueren Linux Kernel basierenden Distrubitionen bieten mitlerweile SVN bei der Installation mit an. Wobei hier einheitlich die SVN cmd Binarytools angeboten werden. Distrubutionen wie Ubuntu oder Debian bieten auch schon FrontEnds wie RapidSVN mit an. | ||
| + | Wie bei Linux gewohnt ist es dem User überlassen, welche Oberfläche er darüberlegt. Ein sehr gutes Programm ist [http://rapidsvn.org/wiki/index.php?title=Main_Page RapidSVN]. | ||
| + | Die passende Bedienungsanleitung kann man unter der [http://rapidsvn.org/wiki/index.php?title=OnlineHelp Onlinehilfe] finden. | ||
| + | |||
| + | Wer eine RPM-basierte Linux-Distrubition nutzt (Fedora, RedHat), kann die benötigten RPMs unter folgenden Links finden: [http://rapidsvn.org/download/ RapidSVN RPM] und [http://subversion.apache.org/packages.html SVN Binaries]. | ||
| + | |||
| + | Die Installation der RPMs erfolgt dann so: | ||
| + | *Shell öffnen und als root einloggen (su -) | ||
| + | *zum Ordner, wo die rpms liegen, wechseln (cd pfad) | ||
| + | *und mit "rpm install packagenamen" installieren | ||
| + | *mit "exit" zum user zurück wechseln und dann mit "rapidsvn" ausführen (im user verzeichnis wird nun ein .rapidsvn ordner mit dem configs abgelegt) | ||
| + | |||
| + | Hinweis: Als erstes die Binary SVN Tools installieren und dann RapidSVN. | ||
| + | |||
| + | Fachwörter wie Commiten oder Checkout verhalten sich wie im Thema Windows beschriebendem TortoiseSVN. | ||
| + | |||
| + | == Lokales Repository == | ||
| + | {{Hinweis|Die folgende Anleitung wurde unter Ubuntu Linux 6.06 getestet.}} | ||
| + | |||
| + | Für private Zwecke reicht meist ein lokales Repository. Dieses lässt sich (zumindest unter Linux) kinderleicht einrichten. | ||
| + | |||
| + | Als erstes wird das Verzeichnis erstellt in dem das Repository verwaltet wird: | ||
| + | |||
| + | Zum Beispiel so: | ||
| + | svnadmin create /tmp/testserver | ||
| + | |||
| + | Beim Auschecken muss nun der absolute Pfad zu diesem Verzeichnis angegeben werden, mit dem Prefix "file://": | ||
| + | |||
| + | cd /tmp | ||
| + | svn checkout file:///tmp/testserver/ test | ||
| + | |||
| + | |||
| + | Das "test" dahinter sagt Subversion das es den neuen Ordner so benennen soll. In dem Beispiel muss diese Angabe gemacht werden, da ansonsten der Ordner testserver genannt wird. | ||
== Tips == | == Tips == | ||
| − | = DGL-Repositories = | + | = Öffentliche DGL-Repositories = |
| + | {{Hinweis|Die Repository befinden sich auf einem Server mit dynamischer IP-Adresse. Gebt also nicht auf, wenn das Repository sich aktuell nicht erreichen läßt. Die Server sind annährend 24/7 online - dies kann jedoch nicht garantiert werden.}} | ||
| − | + | ''' DGL Test ''' | |
| + | |||
| + | Nicht jeder ist den Umgang mit Subversion oder einer anderen Versionierungssoftware gewöhnt und fühlt sich vielleicht ein wenig unsicher. Es wäre natürlich ärgerlich, wenn nun jemand damit beginnen würde, ein Arbeits-Repository für Testzwecke zu verwenden. Damit dennoch nicht jeder selbst einen SVN-Server aufsetzen muss, bietet DGL ein Test-Repository an, bei dem man bedenkenlos herumexperimentieren kann. Es bietet anonymen Schreib- und Lesezugriff und wird in regelmäßigen Abständen immer wieder gelöscht. | ||
| + | |||
| + | svn co http://svn.delphigl.com/test | ||
'''DGLSDK_Linux''' | '''DGLSDK_Linux''' | ||
| Zeile 47: | Zeile 85: | ||
Hier findet die Entwicklung an der Linux-SDK statt. Da viele Komponenten der Windows und Linux-Version identisch sind, finden hier die Hauptarbeiten des Inhaltes statt. Gerade deshalb sollten auch Windows-Nutzer an dieser Version ein hohes Interesse haben. | Hier findet die Entwicklung an der Linux-SDK statt. Da viele Komponenten der Windows und Linux-Version identisch sind, finden hier die Hauptarbeiten des Inhaltes statt. Gerade deshalb sollten auch Windows-Nutzer an dieser Version ein hohes Interesse haben. | ||
| − | + | svn co http://svn.delphigl.com/dglsdk_linux/trunk | |
| − | |||
| − | |||
| − | |||
| − | + | '''WebSVN''' | |
| + | Natürlich kannst Du auch mit deinem Browser auf die Repository zugreifen! | ||
| − | [http:/ | + | [http://svn.delphigl.com/websvn/ Web-Zugriff auf die DGL-Repository] |
Aktuelle Version vom 25. Juli 2011, 23:59 Uhr
(Mehr Informationen/weitere Artikel) {{{1}}} |
 |
Inhaltsverzeichnis
Allgemein
SVN steht für Subversion und ist eine Version Control Software. Subversion ist vergleichbar mit dem bekannteren CVS und versucht zahlreiche Schwachstellen dieses Systems zu verbessern. Es ist davon auszugehen, dass SVN in den nächsten Jahren CVS als Version Control Software ablösen wird. So wechselte z.b. www.kde.org Anfang des Jahres 2005 zu SVN. Oftmals wird diese Art von Software direkt mit OpenSource in Verbindung gebracht, was vermutlich allerdings mehr situationsbedingt ist. So bietet Microsoft für den kommerziellen Bereich SourceSafe an. Subversion ist im Gegensatz dazu allerdings frei - sowohl der Source Code als auch von kostentechnischer Betrachtung her.
Einsatzbereich
Wieso wird Versionierungssoftware gerade im OpenSource-Bereich häufig eingesetzt? Der Grund dafür ist denkbar einfach. Zahlreiche Entwickler werkeln am gleichen Source Code herum. Jeder, der einmal versucht hat, an einem Source Code mit drei Leuten über eine Netzwerkfreigabe zu arbeiten, wird es bei diesem ersten Versuch belassen haben. Während man selbst eine Änderung an einer Datei durchgeführt hat, hat ein anderer in der gleichen Datei bereits Änderungen durchgeführt. Derjenige der zuletzt sichert... gewinnt. ;)
Ein Lösungansatz könnte so aussehen, dass eine Person die Daten entgegennimmt und diese dann zusammen an einen Ort zusammenfügt. Ein Projekt wie KDE würde jedoch bei mehreren hunderten Entwicklern bereits innerhalb weniger Tage ins absolute Chaos stürzen. Aus diesem Grund wurden Versionierungssoftware entwickelt. Stellvertretend für diese Person nimmt der SVN-Server Veränderungen entgegen und speichert diese zentral ins Repository. Zwar verhindert dies nicht, dass zwei Personen am gleichen Code arbeiten, allerdings ist ein Datenverlust ausgeschlossen, da jederzeit eine ältere Revision angesehen werden kann. Zudem ist SVN sogar begrenzt in der Lage, den Source Code aus zwei veränderten Versionen wieder zu einem zusammenzusetzen.
Doch auch ein einzelner Entwickler kann Vorteile beim Einsatz von Subversion erlangen. Wer bereits einmal an einem großen Projekt gearbeitet hat, wird es vielleicht nur zu gut kennen. Ein Modul wird codiert und das Dummy fliegt raus. Damit alles zusammenpaßt, werden auch kleinere Änderungen an anderen Modulen vorgenommen - doch am Ende läuft ein Modul nicht mehr. Vor den Änderungen war dies allerdings noch intakt. Ohne Versionierungssoftware schaut man dann in die Röhre oder muss sich seines Hirnes bedienen. Wurde Subversion verwendet, wäre es möglich, eine ältere Revision zu laden und mit der aktuellen zu vergleichen. Der Fehler, der nun verhindert, dass das Modul läuft, sollte schnell gefunden sein. (Ansonsten sollte man seine Projektplanung dringend überdenken.)
Begriffe
Ein Repository ist die Bezeichnung für ein SVN-Archiv. Innerhalb des Repository werden die einzelnen Revisionen verwaltet. Jedes Mal, wenn jemand etwas in das Repository kopiert, erhält dieser Beitrag automatisch eine neue Revisionsnummer und kann anhand dieser eindeutig identifiziert werden. Es ist jederzeit möglich, Source Code einer älteren Revision auszuchecken.
Um an einen Projekt zu arbeiten, erfolgt zunächst ein Checkout. Hierbei wird eine Kopie des Repository auf den lokalen Rechner kopiert. Dieses steht automatisch unter Versionskontrolle und alle Änderungen daran werden automatisch erfaßt. Sind Änderungen fertig und lauffähig, macht der Programmierer ein Commit und überträgt seine Änderungen wieder an den Server. Der umgekehrte Weg nennt sich Update und gleicht die lokale Version mit der des Repository wieder ab.
Der Aufbau eines Repository ist meistens denkbar einfach. Ein sogenannter trunk (Stamm) stellt den Hauptentwicklungszweig dar. Hier fließen auch kritische Änderungen ein. Sobald ein Release bevor steht wird eine Kopie des trunks als branch (Zweig) erzeugt. Die Entwickler nehmen hier nur noch Bugfixes vor und versuchen Fehler zu beheben. Es werden keine neuen Funktionen eingebaut. Sind keine Fehler mehr vorhanden und die Software gereleast, wird ein tag angelegt. Es handelt sich hierbei um einen aktuellen Snapshoot des Source Codes. Natürlich unterscheidet sich die Art wie die einzelnen Projekte verwaltet wird. Bei dieser Konstellation handelt es sich jedoch um eines der häufigsten und ist z.B. beim KDE-Projekt anzufinden: KDE WebSVN.
Anleitung
Windows
Die Verwendung von SVN ist unter Windows denkbar einfach. TortoiseSVN bietet sich als grafischer Client an und wird direkt in den Windows-Explorer integriert. Wir spielen an dieser Stelle einmal durch, dass wir ein Checkout aus dem DGL-Test-Repository durchführen und eine neue Datei wieder zum Repository hinzufügen. Zunächst bewegen wir uns an die Stelle, an der das Repository angelegt werden soll. Aus dem Kontextmenu des Explorer klicken wir auf SVN Checkout....
Es öffnet sich ein neues Fenster, in dem wir die Position des Repository angeben müssen. Dies kann entweder wie in diesem Beispiele eine ganze gewöhnliche URL sein oder auch ein Repository auf dem lokalen Rechner. Sollte das Zielverzeichnis nicht existieren, werden wir automatisch gefragt, ob dieses angelegt werden soll.
Aus Sicherheitsgründen sind die meisten Repository geschützt und man muss sich zunächst authentifizieren. Im Falle dieses Beispiels ist der Benutzername "public" und das Passwort leer. Sollte kein Fehler auftreten, meldet der SVN-Client, welche Revision gerade ausgecheckt wurde. Im Explorer ist das Repository nun wie ein normaler Ordner zu sehen. Allerdings sollte neben diesem ein grüner Haken sein, der signalisiert, dass die lokale Kopie auf dem neusten Stand ist. Nun betreten wir die Kopie mit einem Doppelklick und erzeugen darin eine neue Datei namens "svntest.txt". Dieses befindet sich nicht automatisch unter Versionskontrolle. Deswegen klicken wir diese mit der rechten Maustaste an und wählen aus dem Kontextmenu "Add" aus. Es erscheint ein neuer Dialog, in dem zusammengefaßt wird, welche Dateien unter Versionskontrolle gestellt werden soll. Beachtet bitte, dass dieser Vorgang nur bei neuen Dateien notwendig ist. Dateien, die bereits aus dem Repository bezogen werden, stehen automatisch unter Kontrolle.
Dies sollte als kleine Einleitung für SVN erst einmal reichen, auch wenn dies nur ein Kratzen an der Oberfläche war.
Linux
Die neueren Linux Kernel basierenden Distrubitionen bieten mitlerweile SVN bei der Installation mit an. Wobei hier einheitlich die SVN cmd Binarytools angeboten werden. Distrubutionen wie Ubuntu oder Debian bieten auch schon FrontEnds wie RapidSVN mit an. Wie bei Linux gewohnt ist es dem User überlassen, welche Oberfläche er darüberlegt. Ein sehr gutes Programm ist RapidSVN. Die passende Bedienungsanleitung kann man unter der Onlinehilfe finden.
Wer eine RPM-basierte Linux-Distrubition nutzt (Fedora, RedHat), kann die benötigten RPMs unter folgenden Links finden: RapidSVN RPM und SVN Binaries.
Die Installation der RPMs erfolgt dann so:
- Shell öffnen und als root einloggen (su -)
- zum Ordner, wo die rpms liegen, wechseln (cd pfad)
- und mit "rpm install packagenamen" installieren
- mit "exit" zum user zurück wechseln und dann mit "rapidsvn" ausführen (im user verzeichnis wird nun ein .rapidsvn ordner mit dem configs abgelegt)
Hinweis: Als erstes die Binary SVN Tools installieren und dann RapidSVN.
Fachwörter wie Commiten oder Checkout verhalten sich wie im Thema Windows beschriebendem TortoiseSVN.
Lokales Repository
|
Die folgende Anleitung wurde unter Ubuntu Linux 6.06 getestet. |
Für private Zwecke reicht meist ein lokales Repository. Dieses lässt sich (zumindest unter Linux) kinderleicht einrichten.
Als erstes wird das Verzeichnis erstellt in dem das Repository verwaltet wird:
Zum Beispiel so:
svnadmin create /tmp/testserver
Beim Auschecken muss nun der absolute Pfad zu diesem Verzeichnis angegeben werden, mit dem Prefix "file://":
cd /tmp svn checkout file:///tmp/testserver/ test
Das "test" dahinter sagt Subversion das es den neuen Ordner so benennen soll. In dem Beispiel muss diese Angabe gemacht werden, da ansonsten der Ordner testserver genannt wird.
Tips
Öffentliche DGL-Repositories
|
|
Die Repository befinden sich auf einem Server mit dynamischer IP-Adresse. Gebt also nicht auf, wenn das Repository sich aktuell nicht erreichen läßt. Die Server sind annährend 24/7 online - dies kann jedoch nicht garantiert werden. |
DGL Test
Nicht jeder ist den Umgang mit Subversion oder einer anderen Versionierungssoftware gewöhnt und fühlt sich vielleicht ein wenig unsicher. Es wäre natürlich ärgerlich, wenn nun jemand damit beginnen würde, ein Arbeits-Repository für Testzwecke zu verwenden. Damit dennoch nicht jeder selbst einen SVN-Server aufsetzen muss, bietet DGL ein Test-Repository an, bei dem man bedenkenlos herumexperimentieren kann. Es bietet anonymen Schreib- und Lesezugriff und wird in regelmäßigen Abständen immer wieder gelöscht.
svn co http://svn.delphigl.com/test
DGLSDK_Linux
Hier findet die Entwicklung an der Linux-SDK statt. Da viele Komponenten der Windows und Linux-Version identisch sind, finden hier die Hauptarbeiten des Inhaltes statt. Gerade deshalb sollten auch Windows-Nutzer an dieser Version ein hohes Interesse haben.
svn co http://svn.delphigl.com/dglsdk_linux/trunk
WebSVN Natürlich kannst Du auch mit deinem Browser auf die Repository zugreifen!
