Für Software-Entwickler ist es von großer Wichtigkeit, nicht nur den jeweils aktuellen Entwicklungsstand der eigenen Projekte verfügbar zu haben, sondern bei Bedarf auch auf alte Versionen Zugriff zu haben – und feststellen zu können, wer eine bestimmte Änderung wann vorgenommen hat. Um alle diese Punkte unter einen Hut zu bekommen, werden heutzutage webbasierte Versionsverwaltungssysteme wie Subversion(SVN) oder Git eingesetzt.
Wer sich den Aufwand für die Einrichtung und die Betreuung eines eigenen Servers ersparen möchte, findet bei uns nach Leistungsbedarf gestaffelte Pakete, die keinen Wunsch offen lassen. Einsteiger nutzen gerne unser einfaches SVN/GIT-Hosting ab 2,90€ pro Monat mit flexibel wählbarem Speicherplatz, fortgeschrittene Entwickler und Teams profitieren von unseren SVN/GIT-Webhosting paketen ab 3,49€ pro Monat. Mit diesen Paketen lassen sich webbasierte Anwendungen wie Projektmanagement, Bugtracker, etc. mit dem Repository kombinieren, sodass ein reibungsloser Workflow möglich wird.
Anspruchsvolle Kunden mit speziellen Anforderungen oder sehr hohem Leistungsbedarf finden bei unseren SVN/GIT-Servern die passende Lösung, je nach Wunsch als VServer, Cloudserver oder dedizierter physischer Server, schon ab 60,90€ im Monat.
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.
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 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.
Trac, Bugzilla, Redmine, Jira, Mantis 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 Bugzilla, Trac, 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.
Während Bugzilla etwas angestaubt wirkt, präsentiert sich Redmine etwas moderner. 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.
Trac ist sehr verbreitet. Durch die verwendetet Sprache Python jedoch auch nicht überall installierbar.
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, Trac, Jira oder anderen Lösungen 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.
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
Copyright © All rights reserved. LCube - Professional Hosting e.K. 2024