Und eine
SVN-Server (wie auch Git und die anderen) verarbeiten alles an Dateien ... am besten allerdings Text-Dateien ... somit also egal, was, wie und womit ich entwickle ... dem
CVS ist das egal (auf Borland Star-Team kann man getrost verzichten)
SVN ist da zwar besser, aber immernoch nicht so toll. So sehr ich auch die "
CVS keywords" (ursprünglich
nur CVS aber in
SVN verfügbar) an sich schätze, ein VCS hat gefälligst nie an meinen Daten rumzufummeln sondern die originalgetreu zu speichern und wieder rauszurücken. Weder
SVN noch
CVS halten sich da dran. Wenn ich schon das Rumgefummel mit den Zeilenumbrüchen sehe, kommt mir das Brechen ...
Bei
SVN wird es auch sehr schnell sehr langsam. Wer einmal mehr als ein Release von Boost verwaltet hat und ohnehin schon ein großes Repo mit mehreren hundert Dateien und tausenden Revision hat, der wird die Geschwindigkeit von
SVN nicht gerade schätzen. Einer der Gründe ist übrigens, daß in der Working Copy (daran wird wohl gearbeitet) immer diese .svn-Verzeichnisse mit Metadaten herumliegen. Und das nicht wie bei Git oder Mercurial nur auf der obersten Ebene sondern in jedem einzelnen Verzeichnis ...
Hab leider noch kein Git unter Linux installiert, also als "Server"-Software, sonst könnte ich da evtl. Hilfe anbieten.
SVN war damals nicht so toll... Hatte es als Apache-Modul mal probiert, aber es gibt eben ein paar Hürden zu nehmen. Das will ich nicht nochmal machen
Vielleicht gibts ja passende Pakete für das installierte Linux?!
Unter Debian und Ubuntu kinderleicht und selbst auf anderen Distros oder BSDs kein größeres Problem.
Das mit dem Apachemodul ist ein wenig ... nunja ... unglücklich. Denn wie auch Git oder Mercurial bietet
SVN schon von Haus aus einen "serve"-Befehl, nämlich
diesen. Nichts anderes passiert ja, wenn man einen
SSH-Tunnel benutzt. Dort wird ja auch auf der entfernten Seite eine Instanz von svnserve gestartet um für den aktuellen Tunnel das Repo bereitzustellen. Ich denke also daß eine Erwähnung des Apachemoduls (mod_dav_svn, nehme ich mal an) nicht gerechtfertigt ist, da es beim Anbieten von Git und Mercurial über Apache ebenfalls Hürden gibt, die aber dann anderer Art sind (Proxy via mod_rewrite).
Bzgl.
SVN via
SSH-Tunnel kann man ja auch anderweitige Benutzung des Kontos direkt verbieten indem man das hier benutzt:
Code:
command="svnserve -t --tunnel-user=BenutzerName",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
ssh-dss AAA ...