SVN Hosting & Git Hosting in Deutschland

Die Arbeitsweise von Subversion ist sehr einfach.

Der Subversion Server speichert lediglich Dateien. Die Dateien sind in sogenannten Repositorys zusammengefasst.
Möchte man auf die Dateien zugreifen muss man sich das betreffende Repository auf seinen lokalen Rechner herunterladen. Dieser Vorgang wird auschecken oder checkout genannt.
Die lokale Kopie eines Repositorys wird Arbeitskopie oder workingcopy genannt.

Das hochladen der Änderungen der lokalen Arbeitskopie passiert mit einem Commit.

Möchte man nun seine Arbeitskopie mit dem Repository auf dem Server abgleichen kann man ein Update durchführen.
Wenn Änderungen in ein und der selben Datei von mehreren Entwicklern durchgeführt wurden versucht der Subversion Client die Version ineinander zu überführen und die Änderungen des Repositorys auf dem Server in die loakle Kopie zu übertragen.
Schlägt das fehl, meldet der Subversion Client ein Konflikt.

Auf diese Weise können mehrere Entwickler an einem Projekt arbeiten und sind in der Lage Änderungen anderer Entwickler in die eigene Arbeitskopie zu übernehmen ohne lokale Dateien zu überschreiben.

Um mit mehreren Entwicklern von überall auf der Welt auf die Repositorys zuzugreifen benötigen Sie ein SVN Hosting. Der SVN Hosting Anbieter hosted die Repositorys und stellt diese über einen Webserver, SVN Server oder SSH Server zur Verfügung.

Damit die Repositorys von überall aus erreichbar sind müssen Sie an einer zentralen Stelle gelagert werden.

In der Regel wird dazu ein Provider verwendete der ein SVN Hosting bzw. Git Hosting anbietet. Eine Inhouse Lösung ist auch möglich sofern das entsprechende Know How für ein solches Hosting vorhanden ist.

Um nun eine lokale Kopie (Arbeitskopie) des Subversion Repositorys zu erstellen kann man aus verschiedenen SVN Clients wählen. Alle bieten sie individuelle Vor- und Nachteile.
Unter Windows ist TortoiseSVN ein sehr beliebter Client. Er bettet sich in den Windows Explorer ein und kann per Kontextmenü verwendet werden.

Der Vorgang um eine lokale Kopie zu erstellen wird Checkout oder Auschecken genannt.
Ist eine Arbeitskopie erstellt kann mit der Arbeit auf dem lokalen Rechner begonnen werden.
Alle Programmierer eines Projektes erstellen sich eine solche Arbeitskopie. Das Repository dient als zentrale Sammelstelle aller Änderungen.

Um Änderungen anderer Programmierer aus dem SVN Hosting Repository in die lokale Arbeitskopie zu integrieren wird die Funktion Update verwendet.
Mit einem Update wird die lokale Arbeitskopie auf den Stand des Repositorys, welches beim Subversion Hosting Anbieter liegt, gebracht, ohne die eigene Arbeit zu zerstören.
Subversion versucht durch ein Merge die im Repository geänderten Zeilen in die lokale Arbeitskopie zu integrieren.

Über unsere selbst entwickelte Benutzeroberfläche können Sie Benutzer und Gruppen für Ihre SVN Hosting und GIT Hosting Repositorys anlegen.
Melden Sie sich dazu in Ihren SVNDevAdmin Account an und gehen dazu links auf Benutzer. Weisen Sie dem Benutezr einen Namen, benutzernamen, EMail Adresse und ein Kennwort zu. Zusätzlich können Sie festlegen ob dieser Benutzer aktiviert oder deaktiviert sein soll.
Deaktivierte Benutzer haben keinen Zugriff auf Repositorys.

Damit der Benutzer auf Ihre Subversion oder GIT Repositorys zugreifen kann müssen Sie ihm entsprechende Rechte einräumen.
Dies machen Sie entweder in den Einstellungen in den globalen Zugriffsrechten (gilt für alle Repositorys) oder in den Zugriffsrechten des jeweiligen Repositorys.

Hier kommen Sie zum Testpaket: SVN Hosting Testaktion

Wer sein Repository bei einem SVN Hosting Anbieter liegen oder selber gehostet hat, kann seine Änderungen am Quelltext für andere Verfügbar machen.
Zuerst wird eine lokale Arbeitskopie von dem SVN Repository auf dem lokalen Rechner erstellt.
Hier kann nach Herzenslust entwickelt werden.
Wenn ein Stand erreicht ist, der anderen Benutzer oder Entwicklern zur Verfügung gestellt werden soll, muss ein Commit über die Subversion Kommandozeilentools oder anderen geeigneten SVN Clients durchgeführt werden.

Subversion bietet zusätzliche noch einige Mechanismen um z.B. andere Entwickler über Änderungen im SVN Repository zu informieren.
Hierzu werden entsprechende Hooks verwendet.
Ein Post-Commit Hook Script kann z.B. so erstellt werden, dass es nach einem Commit eine Mail mit einer Änderungsmitteilung an alle Entwickler schickt.
So bleiben alle auf dem laufenden wenn Änderungen am Repository vorgenommen wurden.
SVN Hosting Anbieter bieten i.d.R. die Möglichkeit die Hook Scripte der Repositorys zu bearbeiten.

Damit andere nun von den Änderungen im Repository des SVN Hosting Anbieters profitieren müssen diese ein Update ihrer lokalen Arbeitskopie durchführen.
Dabei werden alle Änderungen des SVN Repository in die lokale Arbeitskopie integriert ohne die eigenen Änderungen zu zerstören.
Aus diesem Grunde ist die Versionsverwaltung mit Subversion in Verbindung mit einen qualitativ hochwertigen und professionellen Anbieter auch besonders gut für Entwicklerteams geeignet.

Bei einem Update der lokalen Arbeitskopie werden die Änderungen des Repositorys, welches beim SVN Hosting Anbieter liegt, in die Arbeitskopie des lokalen Rechners übertragen.

Bei diesem Update versucht der SVN Client die Änderungen des Subversion Repositorys in die lokalen Dateien zu integrieren.

Wenn Änderungen sowohl in der lokalen Datei als auch in dem Repository vorgenommen wurde wird versucht ein die beiden Dateien ineinander zu überführen.
Bei dieser Überführung kommt es zu einem Konflikt, wenn die Änderungen z.B. an ähnlichen Stellen in den Dateien vorgenommen wurden. In dem Fall ist eine automatische Integration nicht möglich und die lokale Datei bekommt einen Konflikt Status, der manuell aufgelöst werden muss.

Bevor die lokale Arbeitskopie zum Server des SVN Hosting Anbieters übertragen werden kann müssen alle Konflikte beseitigt werden.
Einige Subversion Clients bieten hierzu Unterstützung in Form von Editoren, die sowohl die Datei des Repositorys als auch die Datei der lokalen Arbeitskopie nebeneinander anzeigen.
Änderungen der jeweiligen Datei werden hervorgehoben.
Der Benutzer kann nun selbst entscheiden, welche Änderungen er in sein Datei übernehmen möchte.

Nachdem die Datei bearbeitet wurde wird der Konflikt als aufgelöst markiert.
Nun kann durch ein Commit die Änderungen in das Repository übertragen werden.
Andere Entwickler können somit die Datei beim nächsten Update in Ihre lokale Arbeitskopie integrieren.

In der Webentwicklung werden in der Regel Dateien lokal geändert und per FTP auf den Webserver übertragen.
Wenn ein zweiter Entwickler ebenfalls Dateien ändern möchte darf dieser nicht vergessen, sich aktuelle Version vom FTP Server herunterzuladen.
Vergisst er das, werden die vorherigen Änderungen überschrieben.
Das ist ein Szenario, was wahrscheinlich schon mal jedem Entwickler passiert ist, der mit mehreren Entwicklern oder mit mehreren Rechner (z.B. Bürorechner und Notebook) an einem Projekt arbeitet.
Wenn die Webseite dann nicht mehr läuft ist schnelles handeln gefragt und läuft meistens auf das zurückspielen eines Backups hinaus.

Eine andere Vorgehensweise wäre die Quelltexte bei einem SVN Hosting Anbieter zu lagern. Hier werden alle Änderungen mit einem Client hochgeladen. Die Änderungen jedes Entwicklers werden in die entsprechenden Dateien integriert. Verlorene Änderungen gehören somit der Vergangenheit an.

Einige Anbieter bieten Ihren Kunden die Möglichkeit sogenannte Hooks zu verwenden. SVN Hooks sind Script, die nach bestimmten Vorgängen im Repository vom SVN Hosting Server aufgerufen werden.
So ist es z.B. möglich, bei einer Änderungen des Repositorys, automatisch eine Mail mit der Info und eine Liste der geänderten Dateien an alle Entwickler zu senden.
So ist jeder auf dem Laufenden und weiß, dass er sich die aktuellen Änderungen vom Repository des Subversion Servers herunterladen muss.

Ein weiter Möglichkeit für den Einsatz von Hook Scripten besteht darin, Änderungen an bestimmten Dateien des Repositorys des SVN Hosting Servers per FTP auf einen Webserver hochzuladen.
Der Webserver wäre so mit dem Repository synchron und auch mehrere Entwickler, die an einem Projekt arbeiten könnten so nicht ausversehen die Änderungen anderer Entwickler überschreiben.

Es gibt verschiedene Arten von Versionsverwaltungen. Die zentrale und die verteilte Versionsverwaltung.
Beim SVN Hosting wird eine zentrale Versionsverwaltung verwendet.

Es gibt ein zentrales Repository, welches in der Regel auf einem Server in einem Rechenzentrum gelagert ist.
Jeder Entwickler lädt sich eine lokale Arbeitskopie herunter, ändert Dateien und lädt die geänderten Dateien wieder in das Repository des Subversion Webhosting Servers.
Im Gegensatz zur verteilten Versionsverwaltung stellt die Arbeitskopie lediglich ein Snapshot der aktuellen Version des Repositorys dar.

Weil das Repository auf dem Server des Anbieters der zentrale Sammelort für Änderungen ist, handelt sich beim Subversion um eine zentrale Versionsverwaltung.
Ein anderer bekannter Vertreter der zentralen Versionsverwaltung ist das CVS.
Das Subversion ist das am weitesten verbeiteste zentrale Versionsverwaltungssystem. Am Markt befinden sich einige professionelle Anbieter die Subversion Hosting oder kurz SVN Hosting anbieten.
Da bei einer zentralen Versionsverwaltung das Repository auf dem SVN Server die zentrale Sammelstelle für Änderungen ist, ist die Verfügbarkeit und Erreichbarkeit ein sehr wichtiger Faktor für ein effektives Arbeiten.
Sollte der Server einmal nicht verfügbar sein, bedeutet dies, dass keine Änderungen ein- und ausgecheckt werden können.
Daher verwenden professionelle SVN Hosting Anbieter ausschließlich hochverfügbare Serverplattformen, professionelle Rechenzentren und ausgebildete Techniker um einen Reibungslosen Betrieb der Server und Verfügbarkeit des Systems sicherzustellen.

Wenn man nicht mehr zufrieden mit den Leistungen seines SVN Hosting Anbieters ist oder man von einen inhouse Lösung auf eine professionelle Hosting Lösung für Quelltexte umsteigen möchte, müssen die Subversion Repositorys umgezogen werden.

Je nach Alter und Verwendung des Repositorys befinden sich mehr oder weniger viele Versionen im Repository welche beim Umstieg auf einen anderen Server nicht verloren gehen sollen.
Versionsnummern, Logtexte etc. müssen erhalten bleiben.

Um dies zu realisieren gibt es die Möglichkeit ein Dump zu erstellen. Bei einem Dump wird das komplette Repository inklusive Metadaten in ein Archiv kopiert.
Dieses Archiv kann auf dem Server des neuen SVN Hosting Anbieters eingespielt werden.
Zu beachten ist dabei, dass der alte Anbieter hierzu ein SSH Zugang oder das dumpen per Webinterface zur Verfügung stellen muss da der Befehl svnadmin dump lediglich innerhalb des Dateisystems funktioniert.

Ein SSH Zugang sollte jedoch bei einem professionellen Subversion Hosting ohnehin Standard sein.

Auf dem neuen Subversion Server muss nun lediglich der Befehl svnadmin load verwendet werden um das Dumpfile einzulesen.
Auf den Arbeitskopien der Entwickler muss nun ein relocate durchgeführt werden um diese mit dem Repository auf dem neuen Server zu verbinden.

Sollte ein SSH Zugriff nicht möglich sein und der alte Subversion Hosting Anbieter kein Dump zur Verfügung stellen kann svnsync verwendet werden.
Hierbei wird eine Kopie des Repositoryinhalts in eine neues Repository des neuen SVN Hosting Anbieters erstellt.

Wenn man alleine an einem Projekt arbeitet ist es i.d.R. nicht notwendig, die Quelltexte zentral abzulegen.
Spätestens wenn mehrere Entwickler an einem Projekt arbeiten ist die Nachfrage nach einem Zentralen Ablageort groß.
Hier wird meistens ein SVN Hosting verwendet.
Bei einem solchen Hosting werden die Quelltexte zentral bei einem professionellen Anbieter abgelegt.
Dieser kümmert sich um Verfügbarkeit, Sicherheit, Updates, Backups uvm.

Da alle Entwickler, die an einem Subversion Projekt arbeiten zugriff auf das Repository haben, können diese effizient zusammen arbeiten ohne sich gegenseitig zu behindern.

Änderungen an den lokalen Arbeitskopien werden in das zentrale Repository, welches beim SVN Hosting Anbieter liegt, hochgeladen.
Der SVN Hosting Anbieter sorgt dafür, dass der Server jederzeit verfügbar und die Sicherheit gewährleistet ist.
Trotz hoher Verfügbarkeits- und Sicherheitsrichtlinien werden bei einem professionellen Anbieter zusätzlich noch Backups angelegt, die idealerweise räumlich getrennt gelagert werden.

Redmine und andere Tools können ggf. noch vom Webhosting Anbieter zur Verfügung gestellt werden um ein geeignetes Projektmanagement und Bugtracking zu bieten.

Im Subversion Repository werden die Quelltexte zentral gelagert. Sämtliche Änderungen der Programmierer werden hier gesammelt.
Um ein Projekt effektiv zu verwalten werden jedoch noch weiter Faktoren als nur die Ablage der Quelltexte benötigt.
Ob es nun die Kommunikation unter den Programmierern oder mit den Kunden ist.
Beides kann mit einer Projektmanagementsoftware erreicht werden.

Das Projektmanagement hält eine direkte Verbindung zum Subversion Repository.
Kunden können über eine komfortable Weboberfläche Bugs, Anfragen und Featurerequests erstellen.
Diese Tickets können Programmierer oder Teams zugeordnet werden.
Wenn der Programmierer das Problem gelöst hat, kann er ein direkten Verweis vom Ticket zur Subversion Revisionsnummer mit der Fehlerbehebung erstellen.

Bekannte Projektmanagement Systeme sind Redmine, Mantis oder Jira.

Zahlreiche Plugins für die Projektmanagement System sorgen für eine ausreichende Individualisierung.
Zeitverwaltung, ToDo Listen, Roadmaps, Agile uvm.

Welches System am besten zum jeweiligen Projekt passt muss man anhand individueller Faktoren entscheiden.
Von der verwendeten Programmiersprache bis hin zur Optik und Handhabung sind sie unterschiedlich aufgebaut.
Redmine ist modern aufgebaut und lässt sich direkt mit Subversion und Git verbinden. Jira basiert auf Java und benötigt somit einen Java Hosting Anbieter, der sich auf Installation und das betreiben von Jira Instanzen spezialisiert hat.

Mantis ist in PHP programmiert und sollte somit auf fast jeden PHP/MySQL basierten Speicherplatz laufen.

Als Subversion Server werden Server bezeichnet, die Subversion Repositorys zentral zur Verfügung stellen.

Die Subversion Server können auf unterschiedlichen Betriebssystem realisiert werden.
Weit verbreitet ist jedoch Linux da dieses in der Regel kostenlos ist und sehr stabil arbeitet.

Der Zugriff auf die Repositorys des SVN Servers kann auf vier unterschiedliche Wege passieren:
1. Direkt
2. SSH
3. SVN Serve
4. DAV

Der direkte Zugriff ist auf dem Rechner möglich, auf dem sich das Repository befindet.

Bei dem SSH Zugriff kann sich ein Benutzer über die SSH Konsole auf dem Server anmelden und hat somit Zugriff auf die Repositorys und kann diese über die SSH Verbindung auschecken oder Änderungen übertragen. Die übertragenen Daten werden im SSH Tunnel verschlüsselt.

SVN Serve ist ein Subversion eigenes Protokoll. Dieser ist leicht aufzusetzen. Jedoch hat diese Übertragungsform auch einen großen Nachteil: Die Verbindungen sind unverschlüsselt.

Die letzte Möglichkeit auf einen Subversion Server zuzugreifen ist über das WebDAV Protokoll. Subversion liefert dazu ein Modul, welches im Apache Server eingebunden wird. Da der Apacheserver ein sehr stabiler und hochflexibler Server ist, hat man hier sicherlich konfigurationtechnisch die meisten Möglichkeiten. Nahezu alle Subversion Clients unterstützen den den Zugriff über WebDAV auf Subversion Repositorys.
Die Übertragung kann unverschlüsselt über HTTP oder SSL verschlüsselt über HTTPS erfolgen. Selbstverständlich ist die verschlüsselte Übertragung zu bevorzugen.
Sämtliche Authentifizierungmethoden vom Apache Server können verwendet werden. Somit kann Benutzer in die Datenbank eingetragen werden oder es können Systembenutzer verwendet werden.
Sogar der Zugriff über SSL Client Zertifikate kann realisiert werden.

Wenn man mit mehreren Entwicklern in einem Team arbeitet möchte man in der Regel über Änderungen am Repository zeitnah informiert werden.
Dies könnte zum Beispiel realisiert werden, indem alle Entwickler nach einem Commit per Mail informiert werden. In der Mail stehen alle Dateien mit den geänderten Zeilen. So kann jeder Entwickler abschätzen, ob die Änderungen für seine zukünftigen Entwicklungen relevant sind.

Um das zu realisieren kann man bei Subversion Hooks verwenden.
Hooks sind Scripte die vor oder nach einem bestimmten Vorgang aufgerufen werden.
Es gibt Hooks für:
- post-commit
- post-lock
- post-revprop-Change
- post-unlock
- pre-commit
- pre-lock
- pre-revprop-change
- pre-unlock
- start-commit

Um eine Mail an alle Entwickler noch einem Commit zu senden ist das Script post-commit am besten geeignet.
Hier kann zum Beispiel mit dem Programm commit-email.pl oder mit svnnotify eine Mail verschickt werden.

SVNNotify ist umfangreicher und kann Mails mit einem farbigen Diff erstellen.

Sollten Fehler bei dem Hook Script auftreten werden diese durch den lokalen SVN Client in der Regel nach vorne durchgereicht. Dies macht das Debugging der Hookscripte sehr einfach.
commit-email.pl und svnnotify sollten zum Standardumfang eines Paketes bei einem SVN Hosting Anbieter gehören.

Bei einem SVN Hosting werden die Quelldateien in einem zentralen Repository verwaltet.
Mehrere Entwickler können somit gemeinsam an einer Seite arbeiten ohne sich gegenseitig zu stören.

Was ist nun aber, wenn ein Entwickler ein Modul fertig gestellt hat und dieses Veröffentlichen möchte?
In der Regel lädt er seine Änderungen in das SVN Repository und lädt diese danach per FTP auf den Speicherplatz hoch.
Dies ist relativ aufwendig und fehleranfällig:
- Der Entwickler muss mehrere Schritte durchführen um seine Dateien in das Repository und per FTP hochzuladen
- Wenn komplexe Projekte bearbeitet wurden könnte ein Entwickler vergessen Dateien per FTP auf das Webprojekt hochzuladen

Es gibt mehrere Möglichkeiten diese Probleme zu umgehen:
1. Man verwendet ein Hookscript, mit dem Änderungen im Repository automatisch vom SVN per FTP auf einen Speicherplatz hochgeladen werden.
2. Man führt z.B. per PHP ein svn up auf dem Speicherplatz des Webhostingpaketes durch

Für den ersten Punkt gibt es ein Script welches sich svn2web nennt. Wenn Dateien beim SVN Anbieter geändert werden, werden diese geänderten Dateien automatisch per FTP auf einen Speicherplatz transferiert.

Die zweite Lösung benötigt einen installierten Subversion Client auf dem Speicherplatz des Webhostingpaketes.
Dies könnte man z.B. über eine kleine Verwaltungswebseite, gesichert durch Benutzername/Kennwort über eine htaccess Datei, realisieren.
Sollten Dateien direkt im FTP geändert worden sein, könnte man durch einen SSH Zugang die Änderungen direkt in das Repository des Subversion Hosting Anbieters übertragen.

Subversion als zentrales Versionsverwaltungssystem ist ideal um mit mehreren Entwicklern an einem Projekt zu arbeiten.
Jeder Entwickler arbeitet mit einer lokalen Arbeitskopie und lädt Änderungen in das zentrale Repository, welches beim SVN Hosting Anbieter liegt.

Der Subversion Server spielt hierbei als zentraler Ablageort natürlich eine besonders wichtige Rolle.
Wenn dieser ausfällt können die Entwickler zwar in ihren lokalen Arbeitskopien arbeiten jedoch keine Änderungen in das zentrale Repository übertragen oder abrufen.
Daher ist die Stabilität und Verfügbarkeit der SVN Server besonders wichtig.
Redundanz, Failover, Backup sind nur wenige Stichpunkte, die im Zusammenhang mit Hochverfügbarkeit genannt werden können.

Nur wenn die Plattformen, auf den die Subversion Repositorys oder SVN Server gehostet werden hochverfügbar aufgebaut sind, lohnt sich der Umstieg auf ein solches System.
Dies liegt daran, dass bei einem Serverausfall mehrere Entwickler ggf. untätig warten müssen, bis das Repository auf dem SVN Server wieder verfügbar ist.

Das Projektmanagement kann über Lösungen wie Redmine erfolgen.
Über solche Lösungen können Kunden den Fortschrift des Projektes beobachten, Fehler melden, Anleitungen herunterladen und vieles mehr.
Auch hier ist es wichtig jederzeit erreichbar zu sein.
Eine Nichterreichbarkeit aufgrund eines Serverausfalls ist in der Regel ein Imageverlust vor dem Kunden.
Daher sollte das Hosting von Subversion und Projektmanagement auf einen professionellen Serviceanbieter ausgelagert werden um böse Überraschungen zu vermeiden.

Auch wenn ein Entwickler alleine an einem Projekt arbeitet gibt es doch eine Reihe von Anforderungen die an des Projektmanagement und an das Versionsmanagementsystem gestellt werden.
Diese wären z.B.
- Nachvollziehbarkeit der Quelltextänderungen
- Zugriff auf alte Revisionen
- Archivierung von ausgelieferten Version
- Einfache Überführung von Änderungen in aktuellen Entwicklungszweig
- Zugriff mit mehreren Rechner auf die zentralen Quelltexte

Bei diesen Punkten ist es egal, ob es sich um eine großes Entwicklerteam handelt oder ob ein Entwickler alleine an den Quelltexten arbeitet.
Sie erleichtern so oder so das Arbeiten am Projekt.
Diese Punkte und noch mehr werden von einem SVN Server zur Verfügung gestellt.

Die Einrichtung und Verwendung ist so einfach, dass ein Aufwand durch Einarbeitung und Benutzung kaum entsteht.
Die verfügbaren Clients für alle gängigen Betriebssysteme sind auf nahezu alle Anforderungen zugeschnitten.

Wenn man die Einrichtung und Verwaltung des Subversion Servers an einen professionellen Anbieter abgibt hat man mit der technischen Seite nicht zu tun und kann darauf vertrauen, dass der Subversion Server optimal betreut wird und idealerweise sogar hochverfügbar ist um Ausfallzeiten zu minimieren.
Die Preise für ein solches Hosting bewegen sich in einem Rahmen, der das Einrichten eines eigenen Servers überflüssig macht.

Etwas flapsig formuliert kommt es ganz darauf an. Ob
Hochverfügbarkeit notwendig ist, liegt vor allem am Anforderungsprofil des
Nutzers bzw. der Nutzer. Die gängigen „five nines“, gemeint ist damit eine
Verfügbarkeit von 99,999% im Jahresdurchschnitt, bedeuten, dass der Server im
Jahr weniger als etwa sechs Minuten nicht erreichbar ist. Dafür muss der Hoster
schon einen erheblichen technischen Aufwand treiben, was sich natürlich im
Preis des Hosting-Angebotes niederschlägt.

Zum Vergleich: Einfache Hosting-Angebote liegen
üblicherweise bei 99% Verfügbarkeit im Jahresmittel – es kann also unter
Umständen auch zu wesentlich längeren Ausfällen als 1% des Jahres kommen. Das
klingt immer noch, als wäre es wenig, wer jedoch schon einmal mehr als drei
Tage am Stück nicht auf einen wichtigen Dienst zugreifen konnte, wird das
anders sehen. Noch wesentlich ärgerlicher sind kürzere Downtimes, die sich
dafür öfter wiederholen.

Wer auf sein Repository jederzeit schnellen Zugriff
benötigt, wird also auch das Thema Hochverfügbarkeit im Hinterkopf halten, der
Hobby-Entwickler, der sich auch anderen Dingen widmet, wird sich eher für ein
günstigeres Hosting entscheiden und im Zweifelsfalle erst einmal nur lokal
weiterarbeiten.

Übrigens: Häufig ist es gar kein Ausfall eines Servers, der
die Erreichbarkeit beeinträchtigt, sondern ein Defekt an der Netzwerktechnik,
etwa ein ausgefallener Switch oder eine bei Bauarbeiten beschädigte
Datenstrecke.

Während sich Subversion um die Verwaltung der Quelltexte und
der Änderungen an ihnen kümmert, organisiert Bugzilla als sogenannter
Bugtracker die bei der Entwicklung auftretenden Fehler (Bugs) und
Änderungswünsche (Feature Requests). Als Webanwendung in perl lässt sich
Bugzilla recht einfach installieren, mittels Addon wird dann die direkte
Anbindung zwischen Subversion und dem Bugtracker.

Damit lassen sich dann die Bugs nicht mehr nur komfortabel
verwalten sondern auch gleich mit entsprechenden Revisionen des Sourcecodes im
Repository verknüpfen. Damit kann jeder Nutzer mit entsprechenden
Zugriffsrechten direkt nachvollziehen, welche Änderungen am Code zu welchem
Fehler in der Liste der Bugs gehören.

Selbst für Einzelentwickler ist dieses Tool äußerst
nützlich, da so auch später noch auf einfache Weise Regressionsfehler und
ähnliche Ärgernisse recht einfach lokalisiert werden können. Als freie Software
ist Bugzilla kostenlos erhältlich und stellt so eine ideale Ergänzung für das
eigene Subversion Hosting dar. 

In der Open-Source-Welt ist Bugzilla relativ weit
verbreitet, und selbst große Projekte wie Wikipedia nutzen das Werkzeug
erfolgreich. Dabei gibt es durchaus auch einige kreative Nutzungsideen,
beispielsweise beim Gentoo-Projekt. Dort wird Bugzilla verwendet, bestimmte
Paketversionen der Linux-Distribution zu testen, etwa bei der Überführung von
Packages in den stabilen Zweig der Distribution. 

Durch die
Plattformunabhängigkeit läuft es praktisch auf jedem Webserver, der
Perl-Scripte ausführen kann und eine Datenbankanbindung an MySQL, PostgreSQL
oder Oracle bietet. Zur Bedienung ist dann nur noch ein Webbrowser notwendig.

Die Anbindung von Bugzilla an Subversion kann auf
unterschiedliche Art und Weise geschehen. Wenn beide Systeme auf dem gleichen
Server laufen, wie es häufig der Fall ist, dann reichen ein paar Zeilen Perl
aus, um die Anbindung umzusetzen. Komfortabler wird es mit einem dritten
Werkzeug namens Scmbug. Dessen Einrichtung kostet zwar etwas Zeit, da zuerst
das Handbuch entsprechend konsultiert werden muss, dafür ist die Nutzung später
aber auch wesentlich komfortabler.

Nützlicher Nebeneffekt der Nutzung von Scmbug mit Bugzilla:
Wie der Autor von Scmbug selbst zugibt, erzieht die Software den Nutzer zu
sinnvollem Verhalten, etwa dadurch, dass die Angabe einer Fehlernummer zwingend
notwendig ist. Das mag auf den ersten Blick nach Bevormundung aussehen, sorgt
aber nachhaltig dafür, dass später jederzeit nachvollziehbar ist, was wann von
wem bearbeitet wurde. Gerade für die Arbeit in Teams sind solche
Standardprozeduren unumgänglich, die Nutzung ist also in jedem Falle ein gutes
Training für die Arbeit im Team.

Selbst als Einzelentwickler profitiert man davon, denn
unterm Strich entsteht so bessere Software. Sorgfalt ist bei der
Softwareentwicklung stets notwendig, warum sollte sie also bei der
Dokumentation nicht ebenso eingesetzt werden? Dieses simple Argument ist
vermutlich einer der besten Gründe für die durchgängige Nutzung von Werkzeugen
zur Erleichterung und Verbesserung der Softwareentwicklung.

Obwohl beides Programme aus der Kategorie Bugtracker sind,
unterscheiden sie sich doch deutlich in Funktionsumfang und Anspruch. Während
Bugzilla primär der Verwaltung von Fehlern und Wünschen für die
Weiterentwicklung dient, bietet Trac eine deutlich größere Komplexität,
angefangen vom eingebauten Viewer für Subversion-Repositories bis hin zum
integrierten Wiki.

Trac zielt also deutlicher als Bugzilla auf die Arbeit im
Team, die Collaboration-Features sind bei der Koordination mehrerer Entwickler
eine große Hilfe, da beispielsweise die Projektdokumentation gemeinschaftlich
gepflegt und aktualisiert werden kann. Trotz dieser großen Anzahl eng miteinander
vernetzter Features lassen sich die einzelnen Funktionsblöcke auch separat
benutzen, etwa als reiner Issue-Tracker oder nur als Wiki.

Die große Flexibilität von Trac zeigt sich auch in eher
kuriosen Projekten, wie etwa der kollaborativen Übersetzung des
Subversion-Handbuchs, die mittels Trac koordiniert und verwaltet wird.

Welches der beiden Werkzeuge für das eigene Subversion
Hosting zum Einsatz kommen sollte, ist damit zu einem guten Teil reine
Geschmackssache. Für Trac spricht auf jeden Fall die enge Integration
verschiedener Werkzeuge und die Anbindung an Subversion, Bugzilla ist insgesamt
schlichter und einfacher gehalten, ohne dass wesentliche Features für seinen
eigentlichen Einsatzzweck fehlen. Lediglich die Anbindung an Subversion kann etwas
knifflig sein, je nachdem, welche Vorkenntnisse vorhanden sind.

Ja, JIRA lässt sich auf unterschiedliche Weise mit
Subversion verbinden. Es gibt im Atlassian Marketplace zum Beispiel einige
Plugins, die diese Anbindung umsetzen. Auch die Nutzung eine bereits
vorhandenen Installation von TortoiseSVN lässt sich mit JIRA koppeln, so dass
der persönliche Workflow davon nach der Einrichtung kaum berührt wird.

Zur Einrichtung ist zunächst die Installation des
entsprechenden Plugins für den JIRA Server notwendig. Nach der Einrichtung
dieses Plugins müssen die Clients, also die Rechner von denen aus eingecheckt
werden soll, mit dem zugehörigen Plugin für die Client-Seite ausgestattet
werden. Je nach Art der Subversion-Installation auf Client-Seite gibt es hier diverse
Plugins zur Auswahl.

Da das Verfahren zur Kopplung von Subversion und JIRA im
Prinzip immer gleich abläuft, braucht man dazu keine spezifische Kombination
von Tools sondern kann mit dem arbeiten, was etwa durch ein SVN Hosting
vorgegeben bzw. empfohlen ist. Der Rest ist eine reine Konfigurationsfrage, bei
der es nur noch darum geht, die richtigen Parameter für die Kommunikation
zwischen den beiden Entwicklungswerkzeugen mitzuliefern.

Gibt es im Einzelfall Probleme, kann oftmals der dem
Subversion Hosting zugehörige Support weiterhelfen, auch die Supportangebote
und Foren rund zum Subversion, den jeweiligen Client und JIRA sind eine gute
Quelle für hilfreiche Hinweise.

Ein Cloudserver zeichnet sich vor allem durch gute
Skalierbarkeit und damit gute Kostenkontrolle aus. Er eignet sich somit
besonders für Entwicklerteams die eine hohe Fluktuation aufweisen oder saisonal
sehr unterschiedliche Auslastung aufweisen. Da die Auslastung eines Subversion
Servers vor allem von der Art und Häufigkeit der Check-Ins abhängt, hat die
Arbeitsweise des Teams ebenfalls einen großen Einfluss darauf, wie viele
Ressourcen für die zügige Arbeit benötigt werden.

Für Teams mit wenigen Mitgliedern und/oder eher seltenen
Check-Ins reicht ein „normaler“ SVN Server in der Regel aus. Wenn sich in der
Praxis jedoch herausstellt, dass Check-Ins sehr langsam ablaufen oder es sogar
zu Problemen mit dem Server kommt, sollte ein Upgrade auf eine Cloud-Lösung in
Betracht gezogen werden. Damit lässt sich für Zeiten hohen Leistungsbedarfs
simpel zusätzliche Leistung zubuchen, ohne dass dazu ein Serverumzug oder
ähnliches notwendig wäre. Für Zeiträume, in denen die zusätzliche Leistung
nicht benötigt wird, kann dann wieder auf das Basis-Niveau zurückgeschaltet
werden – das spart Kosten.

Auch die Projektgröße hat natürlich Auswirkungen auf die
Server-Auslastung. Wächst das Projekt mit der Zeit, kann auch hier eine
Anpassung der Serverleistung notwendig sein. Da Projekte sehr unterschiedlich
sein können, gibt es hier wenig Anhaltspunkte, wann es tatsächlich so weit ist
– wenn der Zugriff auf das Repository aber spürbar langsamer wird, sollte man
das Thema Aufrüstung nicht mehr allzu lange vor sich her schieben.

Einen absoluten Zwang dazu gibt es nicht, aber trotzdem ist
es sinnvoll und dringend zu empfehlen. Als Vergleich kann etwa eine Haustür
dienen. Ist dort nur ein simples Zimmertürschloss verbaut, bedeutet das nicht
zwangsläufig, dass Diebe zu Besuch kommen. Dennoch käme niemand auf die Idee,
deshalb statt eines modernen Schließzylinders so etwas zu verbauen.

Bei der Kommunikation mit dem Subversion Server geht es ja
vor allem darum, die Verbindung abzusichern, so dass weder Passworte noch
Inhalte von Dritten ausgespäht werden können. Dazu dient die Verschlüsselung.
Gleichzeitig stellt sie durch die Art und Weise der Umsetzung auch sicher, dass
Client und Server davon ausgehen können, dass sie auch wirklich mit dem
gewünschten Gegenüber kommunizieren und nicht mit einem anderen Rechner, der
sich in die Kommunikation eingeschlichen hat.

Dieses Einschleichen ist auch unter dem Begriff „Man in the
middle“ bekannt. Der fremde Rechner spricht dabei auf der einen Seite mit dem
Client und gibt vor, der Server zu sein. Auf der anderen Seite spricht er mit
dem Server und täuscht dort vor, der Client zu sein, mit dem der Server
eigentlich kommunizieren soll. Dadurch kann der Fremdrechner sämtliche Inhalte
der Kommunikation abgreifen und bei Bedarf verändern.

Durch den Einsatz der Verschlüsselung per SSL bzw. SSH wird
dieses Szenario wirksam unterbunden. Daher ist die Verschlüsselung nicht
zwingend notwendig, aber sehr ratsam.

Nein. Ein Zertifikat benötigen Sie nur, wenn Sie ihre eigene
Domain Dritten gegenüber als authentisch ausweisen möchten. Ansonsten genügt
auch die Erstellung eines sogenannten selbst unterzeichneten Zertifikates. Da
hierbei kein Verwaltungsaufwand durch eine zentrale Stelle, die sogenannte
Certificate Authority (CA), entsteht, fallen dabei keine Kosten an. Bei der
ersten Nutzung des selbst erstellten Zertifikats erhalten Sie auf der
Client-Seite unter Umständen eine Sicherheitswarnung, da diese Zertifikate eben
nicht von dritter Stelle, der CA, aus verifiziert werden können. Überprüfen Sie
sicherheitshalber das angezeigte Zertifikat. Stimmt es mit dem von Ihnen zuvor
selbst erzeugten Zertifikat überein, können Sie es als dauerhafte Ausnahmeregel
in den lokalen Zertifikatsspeicher aufnehmen.

Diese Schritte sind auf jedem Client nur einmal pro
Zertifikat notwendig. Sollten Sie später erneut solch eine Warnung erhalten,
ohne dass sich das Zertifikat geändert hat, so überprüfen Sie bitte Ihren
Server, ob das Zertifikat noch korrekt dort vorliegt.

In Einzelfällen kann solch eine Warnung auch ein Zeichen für
eine lokale Malware-Infektion sein. Überprüfen Sie in diesem Falle den Rechner
unbedingt mit einem aktuellen Virenscanner mit neuesten Signaturen, der von einer
CD oder DVD gestartet wird. So vermeiden Sie, dass die Malware sich im
laufenden Betriebssystem so gut tarnen kann, dass der Virenscanner sie nicht zu
entdecken vermag. Vereinzelt kommt es auch zu Warnungen im Zusammenhang mit
Zertifikaten, wenn die Echtzeituhr des Clients nicht korrekt eingestellt ist.
Da Zertifikate einen beschränkten Gültigkeitszeitraum haben, entstehen diese
Warnung zum Beispiel wenn die CMOS-Batterie leer ist und der Rechner daher mit
einem falschen Datum, z.B. dem 1.1.1980 startet. 

Da die Gültigkeit eines
Zertifikates beschränkt ist, muss es außerdem rechtzeitig „verlängert“ werden,
d.h. es muss ein neues Zertifikat für den existierenden privaten Schlüssel
erzeugt werden.

Je nachdem, welche Inhalte Sie gesichert haben, erfolgt die
Wiederherstellung in mehreren Teilschritten. Am einfachsten ist die
Rücksicherung, wenn das Backup über die Administrationsoberfläche des
Hosting-Accounts angelegt wurde. In der Regel gibt es dort auch das
entsprechende Pendant zur Wiederherstellung. Je nach Größe der Sicherungsdatei
kann es dabei empfehlenswert sein, diese zuvor schon per FTP hochzuladen, da der
Upload von Dateien über den Browser regelmäßig Einschränkungen bei der
erlaubten Dateigröße unterliegt. Dies ist eine leider notwendige
Sicherheitsmaßnahme gegen Angriffe auf den Webserver. Bei der Wiederherstellung
wird dann der Inhalt des Repositorys so rekonstruiert, wie er zum Zeitpunkt der
Backup-Erstellung vorhanden war.

Erfahrene Nutzer können auch über den SSH-Zugang mit dem
Werkzeug svnadmin Backups anlegen und wieder einspielen. Dabei ist allerdings
zusätzliche Handarbeit notwendig, denn hierbei werden weder die
Konfigurationsdateien des Repositorys (und damit unter anderem die
Repository-Nutzer samt Logindaten und Zugriffsrechten) noch die sogenannten
Hook-Scripte gesichert bzw. wiederhergestellt. Dafür erlaubt dieser Weg volle
Kontrolle darüber, was wiederhergestellt wird. Zusätzlich können direkt bei der
Wiederherstellung Änderungen vorgenommen werden, die bei der vollautomatischen
Rücksicherung über die Administrationsoberfläche erst später möglich sind.

Bei Hosting-Paketen, die neben Subversion auch noch
Webhosting beinhalten, sind weitere Schritte zur kompletten Sicherung
notwendig. Das betrifft zum einen die Dateien auf dem Webspace, und zum anderen
die Datenbanken, die zum Paket gehören. Die Dateien lassen sich bequem per FTP
hochladen, danach müssen allerdings gegebenenfalls noch die Zugriffsrechte für
die Dateien korrekt gesetzt werden. Andernfalls kann es zu Fehlfunktionen der
Web-Anwendungen kommen, etwa wenn keine Dateien auf dem Webspace angelegt
werden können oder Scripte nicht ausgeführt werden dürfen.

Die Datenbanken schließlich werden aus den entsprechenden
Dumps wiederhergestellt, in der Regel durch den Import über
Administrationswerkzeuge wie PHPMyAdmin. Dabei wird der bei der Sicherung
erstellte Datenbankdump in eine neu erstellte Datenbank eingelesen. Das
bedeutet, dass auch in der Anwendung, die auf die Datenbank zugreift, die neuen
Zugangsinformationen (Datenbankname, Username und Passwort für den
Datenbankzugriff und der Hostname des Datenbankservers) eingetragen werden müssen.
Sind alle Teile der Wiederherstellung erfolgreich durchlaufen, sollte das
Subversion-Hosting wieder wie gewohnt funktionieren.

Vorausgesetzt, dass nicht etwa Schreibzugriffe für anonyme Nutzer aktiviert sind (was verständlicherweise eine schlechte Idee ist), so lässt sich mit Subversion auch sehr leicht herausfinden, welcher Nutzer wann bestimmte Änderungen vorgenommen hat. Der zugehörige Befehl in Subversion heißt sinnigerweise „Blame“ (engl. für „Schuld, Verschulden“) und liefert eine Übersicht, welcher Nutzer mit welcher Revision des Repositorys Änderungen an einer bestimmten Datei vorgenommen hat. Diese Funktion ist gerade  in neuen Teams sehr wichtig, damit Probleme frühzeitig erkannt werden. Das Paradebeispiel sind zwei Entwickler, die sich nicht ausreichend abgestimmt haben und beide parallel Änderungen an der gleichen Komponente vornehmen. Da Subversion beim Commit neuer Revisionen in der Lage ist, Änderungen oftmals automatisch miteinander zu vereinen, kann dies durchaus eine Weile unentdeckt bleiben.

Irgendwann fällt das Problem letztlich doch jemandem auf, und dann ist anhand der Liste betroffener Revisionen leicht nachzuvollziehen, wer wann welche Änderungen vorgenommen hat. Dieses Werkzeug ist in allen gängigen Subversion-Clients integriert. Wer die Integration in Entwicklungsumgebung oder Windows Explorer nutzt, kann in der Regel direkt über das Kontextmenü nach einem Rechtsklick auf die betroffene Datei die Liste der betroffenen Revisionen abrufen.

Ein Arbeitsschritt bleibt jedoch noch zu tun: Anhand der Liste der Revisionen, bei denen Änderungen der betroffenen Datei vorgenommen wurden, muss ausgewertet werden, welche Änderungen für das entstandene Problem relevant sind. Als Beispiel seien Commits genannt, bei denen nur an der Strukturierung des Quelltextes gearbeitet wurde und kein neuer Code hinzugekommen ist. Bis auf seltene Ausnahmen können solche Commits bei der Recherche ignoriert werden.

Kommt es öfter zu derartigen Problemen bei der Entwicklungsarbeit im Team, kann dies darauf hindeuten, dass die Kommunikation im Team mangelhaft ist, oder einzelne Entwickler nicht teamfähig sind. Je eher diese Probleme entdeckt und angesprochen werden, desto besser lassen sie sich beheben.

Kurz und bündig gesagt: Ja. Subversion lässt sich zwar auch dazu missbrauchen, ohne diese Struktur im Repository zu arbeiten, man verschenkt damit aber einen guten Teil der Fähigkeiten von Subversion. Dazu kommt noch, dass man später immer wieder an einen Punkt gelangen kann, an dem man diese Features doch braucht. Die nachträgliche Umstellung auf die „ordentliche“ Struktur ist mit immensem Aufwand verbunden, deswegen empfiehlt es sich wirklich, gleich von Anfang an die Regeln von Subversion vollständig einzuhalten und umzusetzen.

Für Neueinsteiger zählt darüber hinaus ein weiteres Argument: Überall dort, wo Subversion von Profis genutzt wird, findet man auch die komplette Struktur im Repository vor. Es ist deshalb nicht nur sinnvoll sondern auch empfehlenswert, sich diese Arbeitsweise so früh wie möglich anzueignen.

Dabei gibt es durchaus unterschiedliche Stile in der Nutzung. Welcher davon zum Einsatz kommt, hängt zum großen Teil einfach davon ab, worauf sich die Entwickler einigen. Eine gängige Strategie ist beispielsweise, dass die Version im Trunk immer lauffähig und kompilierbar (soweit es sich um eine Compilersprache handelt) sein sollte. Das bedeutet, dass neuer Code erst dann per Commit ins Repository übertragen wird, wenn er fertig und fehlerfrei ist. Der Nachteil dieser Methode ist, dass unter Umständen eine größere Menge Code verloren gehen kann, der noch nicht ins Repository übertragen wurde.

Eine andere Variante ist, im Trunk eine stabile Version zu fixieren, und Branches für die darauf aufbauende, durchaus ab und zu instabile oder unfertige Entwicklerversion zu verwenden. Dann kann jederzeit auch eine kleine Änderung ins Repository übertragen werden, ohne die Release-Version im Trunk zu beeinflussen. Später lassen sich die Änderungen aus den Branches bei Bedarf in den Trunk übertragen, um eine neue stabile Version zu erzeugen.

Weiterführende Details zum Umgang mit dem Repository bietet etwa das umfangreiche SVN-Buch von redbean, das in elektronischer Form kostenlos erhältlich ist, aber auch als Buch angeboten wird.

Bei der Frage nach der Häufigkeit der Commits scheiden sich die Geister. Es gibt mehrere Strategien, die man hier verfolgen kann, abhängig vom Arbeitsstil, Projektvorgaben oder auch bedingt durch die Arbeitsweise anderer Entwickler am Projekt. Eine einzige richtige Antwort gibt es daher schlichtweg nicht, jedes Vorgehen hat seine eigenen Vor- und Nachteile. Als Faustregel kann man im Hinterkopf behalten, dass ein Change Set (also die Summe aller Änderungen zwischen zwei Revisionen des Repositorys) umso kleiner ist, je häufiger der Commit durchgeführt wird. Häufige Commits sind vorteilhaft, da kleine Change Sets die Entwicklung zwischen einzelnen Revisionen besser erkennbar machen und Fehler so leichter behoben werden können. Auf der anderen Seite können übermäßige Mengen von Commits natürlich auch die Übersichtlichkeit negativ beeinflussen.

Einzelentwickler können dabei einfacher ausprobieren, mit welcher Methode sie besser, also produktiver, arbeiten. Im Team muss ein Konsens gefunden werden, der entweder die Eigenheiten der Teammitglieder berücksichtigt, oder diesen eine gemeinsame Strategie zur Nutzung des Repositorys auferlegt. Besser ist dabei natürlich die Lösung, die den einzelnen Entwickler am wenigsten stört. Letztlich beeinträchtigt jede Irritation die Produktivität des Entwicklers, es ist also im Sinne aller Beteiligten, eine möglichst pragmatische, praxisorientierte Lösung zu finden, statt am grünen Tisch eine mehr oder weniger willkürlich gewählte Linie umzusetzen.

Tags sind eigentlich nichts anderes als eine Art Etikett. Durch sie kann eine bestimmte Revision im Repository mit einem Namen versehen werden. Ein gängiger Einsatzzweck für Tags ist beispielsweise, eine bestimmte Release-Version im Repository zu markieren. So ist später jederzeit nachvollziehbar, dass etwa der Release-Stand 2.1 der Revision #6143 im Repository entspricht. Das ist besonders für sogenannte Regressionstests wichtig, mit denen automatisiert getestet werden kann, ob sich ein bereits behobener Fehler nicht nur spätere Änderungen wieder eingeschlichen hat.

Natürlich sind Tags nicht auf diesen einzigen Zweck beschränkt. Was der Entwickler letztlich mit der Funktion umsetzt, ist ihm selbst und seinem Erfindungsreichtum überlassen. Subversion selbst behandelt Tags wie jede andere Information im Repository auch.

Die Dateien tatsächlich aus dem Repository zu entfernen, ist mühsam und nicht empfehlenswert, denn eigentlich ist Subversion darauf ausgelegt, nichts was einmal im Repository hinterlegt wurde, jemals wieder zu vergessen. Dieser inkrementelle Ansatz ist die Voraussetzung dafür, dass jede Revision des Repositorys auch später jederzeit wieder abgerufen werden kann. Für den normalen Arbeitsablauf gibt es aber dennoch eine Funktion, um Dateien, die obsolet geworden sind oder irrtümlich hinzugefügt wurden, als gelöscht zu markieren. Beim nächsten Commit markiert Subversion die Datei im Repository dann ab dieser Revision als gelöscht, gleichzeitig wird die Datei auch lokal gelöscht.

Wichtig ist dabei, die Datei nicht von Hand zu löschen, sondern Subversion bzw. den Subversion Client die Arbeit machen zu lassen. Sonst kann es vorkommen, dass die Datei beim nächsten Abrufen der letzten Revision aus dem Repository wieder neu angelegt wird. Nutzer von TortoiseSVN sowie von Clients, die in Entwicklungsumgebungen integriert sind, haben dabei den größten Komfort. Über einen Rechtsklick auf die „falsche“ Datei im Windows Explorer oder der Entwicklungsumgebung genügt, um die entsprechenden Optionen im Kontextmenü präsentiert zu bekommen.

Auf der Kommandozeile ist dieser Vorgang ebenfalls keine komplizierte Angelegenheit. Der entsprechende Befehl für svn lautet „delete“ und benötigt, sofern keine Sonderbehandlung gewünscht wird, lediglich den Namen der Datei, die aus dem Repository entfernt werden soll. Als Standardverhalten wird dabei die lokale Datei sofort gelöscht, damit keine Verwirrung entstehen kann. Um diesen Status ins Repository zu übertragen, ist wie üblich ein Commit notwendig.

Für Sonderfälle bietet der Befehl noch einige weitere Optionen, deren Beschreibung aber der manpage bzw. dem Subversion-Buch überlassen bleiben soll. Mit diesen Optionen ist es zum Beispiel möglich, die lokale Datei trotz Entfernung aus dem Repository zu behalten, oder die Entfernung einer Datei zu erzwingen, obwohl sie seit dem letzten Commit verändert wurde. Solche Dateien werden ansonsten nicht gelöscht, da dies der Philosophie von Subversion deutlich widerspricht.

Ein SVN Hosting kann für verschiedene Zwecke genutzt werden.

Sinn und Zweck von Subversion ist es jedoch eine lokale Arbeitskopie mit einem zentralen Server zu synchronisieren.

Die Synchronisierung findet dabei nicht kontinuierlich statt sondern wird vom Benutzer angestossen. Werden Änderungen vom Entwickler zum Server geschickt spricht man von einem Commit. Wenn dei Änderungen vom Server in die lokale Arbeitskopie integriert werden soll wird ein Update gestartet.

Auf diese Weise können mehrere Entwickler jeweils Ihre Änderungen zum Server comitten und andere Entwickler führen lokal ein Update durch um die Änderungen in Ihre Arbeitskopie zu integrieren.

Da zum Synchroniseren ein zentraler Server verwendet wird, wird beim Subversion von einem zentralen Versionsverwaltungssystem gesprochen.

Die Alternative zum zentralen System bietet das Git als dezentrales Verwaltungssystem da hier die Repositorys jeweils zum Server auch lokal vorgehalten werden.

SVN ist ein quelloffenes zentrales Versionskontrollsystem.

Alle Änderungen an einer Datein werden in einer zentralen Datenbank gepflegt und sind einzeln Abrufbar. Auf diese Weise kann man jederzeit zu einen bestimmten Stand der Datei (Version/Revesion) zurückkehren.

Häufig wird SVN zur Versionierung von Quelltexten verwendet aber manche verwenden es auch für die Dokumentenverwaltung. Der Andwendungszweck ist vielseitig.

Es können auch Binärdateien Versioniert werden. Mit einem SVN Hosting kann man die zentrale Datenbank von überall aus erreichbar machen. 

Da SVN ein zentrales Versionskontrollsystem ist, muss der aktuelle Stand aus der zentralen Datenbank gelade (ausgecheckt) werden.

Dieses checkout wird auf dem Arbeitsplatzrechner, an dem gearbeitet werden soll durchgeführt.

Entweder man verwendet ein spezielles Programm dafür oder die Subversion Kommandozeilentools.

TortoiseSVN ist zum Beispiel ein sehr bekanntes und gut entwickeltes Programm. Hier brauche Sie im Explorer lediglich über die rechte Maustaste das Kontextmenu aufrufen und auf Checkout klicken. Geben Sie dann die Daten Ihres SVN Hosting Speicherplatzes ein und bestätigen Sie den Dialog.

Über das Subversion Tools lautet der Befehl "svn co https://Servername/Repository"

Ja.

Wir können eine beliebige Domain in Ihre Subversion Paket einbinden und Ihnen so den Zugang zu Ihren Repositorys über Ihre Domain realisieren.

Ein SSL Zertifikat für die Domain sorgt für die notwendige Verschlüsselung und Ihre Daten optimal zu schützen.

Fragen Sie uns, wir beraten Sie gerne.

Ja.

Gerne bieten wir Ihnen ein Testpaket für das SVN Hosting an. Der Test ist vollkommen unverbindlich und natürlich kostenlos. Wir freuen uns auf Ihre Bestellung.

Hier kommen Sie zum Testpaket: SVN Hosting Testaktion

Ja. Auf Ihre Git-Repositorys greifen Sie per SSH mit Public/Private-Key-Authentifizierung oder per HTTPS zu. Gerade für Server-Synchronisierungen ist der Zugriff per SSH-Key komfortabel, weil keine Passwörter gespeichert werden müssen.