SVN: Unterschied zwischen den Versionen
K (→Öffentliche DGL-Repositories: Neue Adressen) |
K (→Öffentliche DGL-Repositories: websvn) |
||
| Zeile 62: | Zeile 62: | ||
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 herum experimentieren kann. Es bietet anonymen Schreib- und Lesezugriff und wird in regelmäßigen Abständen immer wieder gelöscht. | 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 herum experimentieren kann. Es bietet anonymen Schreib- und Lesezugriff und wird in regelmäßigen Abständen immer wieder gelöscht. | ||
| − | [http://svn.delphigl.com/ | + | [http://svn.delphigl.com/websvn/listing.php?repname=testsvn&path=%2F&sc=0 svn co http://svn.delphigl.com/test] |
'''DGLSDK_Linux''' | '''DGLSDK_Linux''' | ||
| Zeile 68: | Zeile 68: | ||
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. | ||
| − | [http://svn.delphigl.com/ | + | [http://svn.delphigl.com/websvn/listing.php?repname=dglsdk_linux&path=%2F&sc=0 svn co http://svn.delphigl.com/dglsdk_linux/trunk] |
| Zeile 75: | Zeile 75: | ||
Dieses Repository enthält den aktuellen Stand der Quake3-Übersetzung. Mehr Informationen zu diesem Projekt findet Ihr auf der [http://quake3.delphigl.com seperaten Webseite] des Projektes. Es wäre schön, wenn sich für die Arbeiten weitere freiwillige Helfern finden würden. | Dieses Repository enthält den aktuellen Stand der Quake3-Übersetzung. Mehr Informationen zu diesem Projekt findet Ihr auf der [http://quake3.delphigl.com seperaten Webseite] des Projektes. Es wäre schön, wenn sich für die Arbeiten weitere freiwillige Helfern finden würden. | ||
| − | [http:// | + | [http://svn.delphigl.com/websvn/listing.php?repname=quake3&path=%2F&sc=0 svn co http://svn.delphigl.com/quake3/trunk] |
Version vom 1. März 2006, 18:26 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 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 darinne aussehen, dass eine Person die Daten entgegen nimmt und diese dann zusammen an einen Ort zusammenfügt. Ein Projekt wie KDE würde jedoch bei zig 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 zusammen zu setzen.
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 zusammen paß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 *sg).
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 an Hand 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 uns 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 eine neue Datei namens "svntest.txt" darinne. 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 welchen Oberfläche er darüber legt. Ein sehr gutes Programm ist RapidSVN. Die passende Bedienungsanleitung kann man unter der Onlinehilfe finden.
Wer eine RPM basierende Linux Distrubition nutzt(Fedora, RedHat, Debian) 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.
Tips
Öffentliche DGL-Repositories
ACHTUNG Die Repository von DGL werden aktuell angepaßt und es kann zu Ausfällen kommen. Wer bereits zuvor mit den Repository gearbeitet hat, sollte darauf achten, dass sich die Ports geändert haben und nicht mehr auf Port 8080, sondern 80 gearbeitet wird. Auch wurden die Adresse teilweise verkürzt.
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 herum experimentieren 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
Quake3
Dieses Repository enthält den aktuellen Stand der Quake3-Übersetzung. Mehr Informationen zu diesem Projekt findet Ihr auf der seperaten Webseite des Projektes. Es wäre schön, wenn sich für die Arbeiten weitere freiwillige Helfern finden würden.
