Diskussion:Subversion im CS-Netz

Fragen zur Einrichtung von SVN im Netz

• Jou, moin, ist zwar keine Frage, aber ein Aspekt den man vielleicht dem Artikel noch hinzufügen könnte: Sicherheit. Ich habe den Artikel nur kurz überflogen, deswegen kann es unter Umständen schon enthalten sein.
  • chmod -R g+rX $MYREPO bedeutet ja, dass $HOME und alle Unterverzeichnisse auf dem Weg zu $MYREPO mindestens chmod g+x haben müssen?! Was bedeutet, dass im eigenen Interesse alle weiteren Dateien/Verzeichnisse auf höchstens chmod 0700 gesetzt werden sollten, wenn die Gruppenmitglieder nicht Einsicht auf private Files haben sollen. Besonders spannend wird es nämlich im nächsten Punkt.
  • Wenn die Gruppenmitglieder Zugriff auf $HOME haben und der vorherige Punkt nicht befolgt wurde, dann haben sie auch Zugriff auf ~/.subversion/auth/svn.simple/* (wenn der Besitzer gerne mal mit chmod -R rum spielt :P), wo (falls vorhanden) alle schon mal benutzten SVN-Passwörter im Klartext drin stehen (default Einstellung [Selbst bei Debian]). Das bedeutet, dass mindestens (im eigenen Interesse) in ~/.subversion/config folgende Zeile `entkommentiert' werden sollte: store-passwords = no. Außerdem ist es sinnvoll auch den Benutzernamen nicht zu speichern, dazu im gleichen File # store-auth-creds = no entkommentieren. Danach sollte man (falls vorhanden) den kompletten Authentifizierungs-Cache löschen: rm -rf ~/.subversion/auth/* (Dabei gehen keine Repository- bzw. Sandbox-Informationen verloren, allerdings die gespeicherte Kennwörter, Benutzernamen und erlaubte Server-UUID's in Verbindung mit den gestatteten Zertifikaten (SSL & Co. [Muss beim nächsten co, up, ci, ls, etc. neu bestätigt werden.].).). ... Sieht auch nett aus: `.].).).' :P

--Der Dirk 15:35, 24. Sep. 2007 (CEST)

PS: Default ist, dass SVN ~/.subversion/auth auf chmod 0700 setzt. Aber immer daran denken, es gibt auch so etwas, was sich `root' nennt, auch im CS Netz ;) ...

Subversive

• Ich kann für Eclipse persönlich Subversive Subversive bei Polarion sehr empfehlen, da es -meiner subjektiven Erfahrung nach-

• stabiler ist
• mehr Implementationen von SVN (unter anderem eine sehr empfehlenswerte 100% Java-Implementation die u.a. auch mit SVN-Ports abseits von 22 umgehen kann) bietet
• die empfohlenen Strukturen um trunk, branches, ... besser unterstüzt
• Multiprojektordner besser kann
• einen klasse Mergeview hat

• Polarion ist ein Anbieter von Teamzusammenarbeitssoftware, deren einer Teil halt Subversive ist, des netterweise halt kostenlos gibt. --Joti 16:43, 5. Jan. 2008 (CET)

SVN+JavaHL funktioniert nicht mehr unter Windows

• Seit kurzem (~28.Juni 08) funktioniert bei mir und einem Kommilitonen im CS-Netz keine SVN-Operation unter Windows (XP und Vista) mehr mit dem Konnektor "JavaHL", vielleicht können es auch andere Konnektoren sein. Der Fehler lautet in etwa "Pfad nicht gefunden" oder "svn: Tunnel-Aufbau nicht möglich". Zumindest unter Eclipse (Subclipse bzw. Subversive) hilft eine Umstellung auf "SVNKit", versucht also, den Konnektor zu wechseln falls ihr damit auch Probleme habt (Eclipse > Window > Preferences > Team > SVN). Unter Linux gibt es merkwürdigerweise keine Probleme...

andere Frage

leider bin ich nicht so der Linux-crack, aber bei mir funktionierte:

chgrp -R $GROUP $MYREPO

nicht.

=>chgrp: xxx : No such file or directory

Sollte das etwa

chgrp -R $GROUP svn-repo

heißen? das ging nämlich

matthias

Richtig, du musst $MYREPO durch den Namen des Repository-Verzeichnis ersetzen 89.247.24.16 15:08, 10. Sep. 2008 (UTC)

SVN über Https

Hallo allerseits,

gibt es Euer Wissen nach eine einfache Variante svn mit https im Uninetz zu koppeln? Leider stosse ich aufgrund restriktiver Portsperrung auf Schwierigkeit, wenn ich über ssh arbeiten möchte.

Danke für Eure Hilfe und danke für das Tutorial ...

Viele Grüße, Fadi Chabarek

SVN und TubIT

Ein kleiner Erfahrungsbericht zu Thema SVN und TubIT:

Das erste Problem, abseits der ganzen Rechte Problematik, ergab sich schon mit dem Standard-ssh-Server der Tubit (sshgate.tu-berlin.de).
Ein "svn co svn+ssh://{user}@sshgate.tu-berlin.de/..." führte unerwarteterweise zu einem "sh: svnserve: command not found". Unerwartet deshalb, weil bei einem normalen ssh-login alle svn-tools an Ort und Stelle und auch im PATH sind. Ob das jetzt am AFS und Verzeichnissen die on-demand gemountet werden liegt, oder die svn-shell einfach nen anderes Profil/Path bekommt, hab ich nicht rausbekommen.

Stattdessen habe ich einen der CS-Server, die ssh-login mit tubit-Daten erlauben (hombre, um genau zu sein), genommen. Die Version von Subversion ist zwar nicht mehr die aktuellste (1.4.5), aber ausreichend.
Das svn wurde direkt im afs-Baum angelegt, sprich unter /afs/tu-berlin.de/home/{anfangsbuchstabe}/{tubit-username}/svn-repos/{repo-name}.

Die nötigen acl-Einträge (die ich noch für jeden zusätzlichen User {tubit-login} einzeln eingetragen hab, da ich nicht weiß, ob und wie man Gruppen anlegen kann) waren dann:

• l für die Verzeichnisse /afs/.../{tubit-username} und /afs/.../{tubit-username}/svn-repos, mittels "fs setacl -acl {tubit-login} l -dir ." im jeweiligen Verzeichnis und
• die Rechte für das eigentliche Repository (und alle Unterverzeichnisse), mit denen ich mit Sicherheit weit über das Ziel hinausgeschossen bin, aber mit rlidwk für die anderen User funktioniert es auf jeden Fall =).
  Da fs Rechte scheinbar nicht rekursiv setzen kann, tut es folgendes:
  im Verzeichnis /afs/.../{tubit-username}/svn-repos ein "find {repo-name} -exec fs setacl -acl {tubit-login} rlidwk -dir {} ';'" ausführen.

Ein Checkout funktionierte dann bei den Usern für die Rechte eingetragen wurden ganz normal mit "svn co svn+ssh://{tubit-login}@hombre.cs.tu-berlin.de/afs/tu-berlin.de/home/{anfangsbuchstabe}/{tubit-username}/svn-repos/{repo-name}" und auch ansonsten scheint soweit erstmal alles zu funktionieren.

Ich hoffe, das ist erstmal nützlich und jemand mit etwas mehr Ahnung kann mal Bescheid sagen, welche Rechte wirklich gebraucht werden... =)

--Jf 16:53, 19. Apr. 2009 (UTC)