Subversion - Versionsgeschichte

Kowa am 1. März 2023 um 11:02 Uhr

2023-03-01T11:02:04Z

← Nächstältere Version		Version vom 1. März 2023, 11:02 Uhr
Zeile 26:		Zeile 26:

	==Server einrichten==		==Server einrichten==
	Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des ~~Projektes~~ inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.		Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projekts inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.

	Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:		Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:

Kowa am 1. März 2023 um 11:01 Uhr

2023-03-01T11:01:13Z

← Nächstältere Version		Version vom 1. März 2023, 11:01 Uhr
Zeile 7:		Zeile 7:
	}}		}}
	==Definition==		==Definition==
	Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt\|~~Projektes~~]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.		Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt\|Projekts]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.

	==Subversion==		==Subversion==

Kowa am 25. September 2018 um 07:11 Uhr

2018-09-25T07:11:09Z

← Nächstältere Version		Version vom 25. September 2018, 07:11 Uhr
Zeile 1:		Zeile 1:
	{{Qualität		{{Qualität
	\|correctness = 3		\|correctness = 3
	\|extent = 5		\|extent = 3
	\|numberOfReferences = 4		\|numberOfReferences = 4
	\|qualityOfReferences = 4		\|qualityOfReferences = 4

Kowa am 24. September 2018 um 16:21 Uhr

2018-09-24T16:21:23Z

← Nächstältere Version		Version vom 24. September 2018, 16:21 Uhr
Zeile 103:		Zeile 103:
	* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]		* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]
	* Karl Fogel, Moshe Bar, Open-Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x		* Karl Fogel, Moshe Bar, Open-Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x
	* CollabNet, Inc., Subversion Homepage, [http://subversion.~~tigris~~.org/ Subversion-Homepage]		* CollabNet, Inc., Subversion Homepage, [http://subversion.apache.org/ Subversion-Homepage]
	* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)

	==Siehe auch==		==Siehe auch==
	*[~~http~~://de.wikibooks.org/wiki/~~Versionskontrolle_mit_Subversion~~ Wikibooks: ~~Versionskontrolle mit~~ Subversion]		*[https://en.wikibooks.org/wiki/Subversion Wikibooks: Subversion]
	*[[Subversion/HowTo]]		*[[Subversion/HowTo]]

Kowa am 24. September 2018 um 16:18 Uhr

2018-09-24T16:18:04Z

Änderungen zeigen

Kowa am 2. November 2015 um 14:49 Uhr

2015-11-02T14:49:20Z

← Nächstältere Version		Version vom 2. November 2015, 14:49 Uhr
Zeile 1:		Zeile 1:
	=Definition=		==Definition==
	Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt\|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.		Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt\|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.

	=Subversion=		==Subversion==
	Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System\|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.		Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System\|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.

	==Hauptvorteile==		===Hauptvorteile===
	Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:		Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:
	* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.		* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.
Zeile 18:		Zeile 18:
	Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).		Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).

	=Server ~~Einrichten~~=		==Server einrichten==
	Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.		Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.

Zeile 41:		Zeile 41:
	Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.		Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.

	==Client-Zugriff==		===Client-Zugriff===
	Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].		Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].

Zeile 76:		Zeile 76:
	Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.		Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.

	==Beispiele für weitere Subversion-Clients==		===Beispiele für weitere Subversion-Clients===

	Siehe [[Subversion/HowTo\|Subversion-Beispiele]].		Siehe [[Subversion/HowTo\|Subversion-Beispiele]].

	=Geschichte=		==Geschichte==
	==SCCS==		===SCCS===
	Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.		Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.

	==RCS==		===RCS===
	Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source\|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.		Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source\|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.

	==CVS==		===CVS===
	Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.		Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.

	=Quellen=		==Quellen==
	* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]		* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]
	* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178		* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178
Zeile 99:		Zeile 99:
	* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)		* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)

	=Siehe auch=		==Siehe auch==
	*[http://de.wikibooks.org/wiki/Versionskontrolle_mit_Subversion Wikibooks: Versionskontrolle mit Subversion]		*[http://de.wikibooks.org/wiki/Versionskontrolle_mit_Subversion Wikibooks: Versionskontrolle mit Subversion]
	*[[Subversion/HowTo]]		*[[Subversion/HowTo]]

Kowa am 7. Oktober 2014 um 09:37 Uhr

2014-10-07T09:37:25Z

← Nächstältere Version		Version vom 7. Oktober 2014, 09:37 Uhr
Zeile 64:		Zeile 64:
	<code>svn ci -m "<Log-Message>"</code>		<code>svn ci -m "<Log-Message>"</code>

	Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum ~~Schluß~~ die neue Revision des Repositories.		Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluss die neue Revision des Repositories.

	Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein [[Merge-Konflikt]] auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.		Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein [[Merge-Konflikt]] auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.

Kowa: /* Siehe auch */

2009-05-18T07:25:06Z

Siehe auch

← Nächstältere Version		Version vom 18. Mai 2009, 07:25 Uhr
Zeile 101:		Zeile 101:
	=Siehe auch=		=Siehe auch=
	*[http://de.wikibooks.org/wiki/Versionskontrolle_mit_Subversion Wikibooks: Versionskontrolle mit Subversion]		*[http://de.wikibooks.org/wiki/Versionskontrolle_mit_Subversion Wikibooks: Versionskontrolle mit Subversion]
			*[[Subversion/HowTo]]

	[[Kategorie:Versionsverwaltung]]		[[Kategorie:Versionsverwaltung]]

Kowa: /* Beispiele für weitere Subversion-Clients */

2009-05-18T07:24:09Z

Beispiele für weitere Subversion-Clients

← Nächstältere Version		Version vom 18. Mai 2009, 07:24 Uhr
Zeile 78:		Zeile 78:
	==Beispiele für weitere Subversion-Clients==		==Beispiele für weitere Subversion-Clients==

	Siehe [[Subversion/~~Beispiel~~\|Subversion-Beispiele]].		Siehe [[Subversion/HowTo\|Subversion-Beispiele]].

	=Geschichte=		=Geschichte=

Kowa am 23. März 2009 um 11:31 Uhr

2009-03-23T11:31:41Z

← Nächstältere Version		Version vom 23. März 2009, 11:31 Uhr
Zeile 75:		Zeile 75:

	Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.		Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.

			==Beispiele für weitere Subversion-Clients==

			Siehe [[Subversion/Beispiel\|Subversion-Beispiele]].

	=Geschichte=		=Geschichte=
Zeile 85:		Zeile 89:
	==CVS==		==CVS==
	Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.		Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.

	~~=Beispiele für Subversion-Clients=~~

	~~Siehe [[Subversion/Beispiel\|Subversion-Beispiele]].~~

	=Quellen=		=Quellen=