SVN unter CentOS 5

[paykoman]

HuHu,

da bin ich wieder *gg*
Nun arbeite ich an diesem Tutorial und habe wie unter Suse, das selbe Problem das sich nirgenswo ein svn Ordner befinder, weder in /var/ noch in /srv/.

Sprich ich werde dort wohl selber einen Ordner anlegen, aber wie bekommt er die entsprechenden Rechte das Sie dann auch von svn genutzt werden?

Wenn ich den schon manuell mache, würde ich den direkt ins homverzeichnis machen, also /svn/repos/, dann spare ich mri schonmal etwas durcheinander.

LG: Paykoman
::EDIT::

was ich viel mehr meinte ist, chmod 755 wie srv und Gruppe etc. dann bei root belassen oder muss ich da iwas umstellen für svn?

[paykoman]

Hi,

das Problem habe ich Theoretisch hinter mir.
Bins noch mal von vorne alles durch und soweit scheint das zu funktionieren....

Jetzt habe ich aber das problem das in diesem Tutorial nicht beschrieben ist wie ich das ganze nun auch unter einer Domain bekomme, denn so ist svn ja nicht ansprechbar.

habe Plesk auf dem Server druff habe die Domain angelegt und arbeite mich durch die configs aber da ich da nicht die Ahnung habe wird mir das wohl eher nicht gelingen.

Also eigentlich müssten nur noch die configs wohl angepasst werden das die Domain eben auf svn arbeitet und nciht mehr das alte httdocs...

Fals mir das einer am Server einstellen würde wäre mir das 25€ wert. Bei Interesse einfach ICQ adden:

293550907

MFG: Paykoman

::EDIT::
mittlerweile habe ich auch das gelöst.
Ich kann nun die url aufrufen und anschliessend die Logindaten des SVN users eingeben.

Der Login scheint ebenfals zu funktionieren leider erfolgt dann die Meldung:

Code: Select all

<D:error>
<C:error/>
<m:human-readable errcode="2">
Could not open the requested SVN filesystem
</m:human-readable>
</D:error>

ja und hier bin ich dann jetzt gänzlich aufgeschmissen, da ich nit weis wo was ich an rechte anpassen muss..

änder ich die usergruppe von dem ordner svn so wird svn selber warscheinlich nciht mehr mit dem Ordner arbeiten können also Zwickmühle .(

Kann mir da einer nen tipp geben?

LG: Paykoman

[daemotron]

Ich habe im Wiki mal beschrieben, wie man unter CentOS einen Subversion-Server per WebDAV aufsetzt: http://www.rootforum.org/wiki/Konfigura ... on-Servers

[daemotron]

Mit Lighty geht's technisch nicht - es gibt schlicht und ergreifend kein mod_dav_svn für Lighty. Und man könnte auch so leicht keines schreiben, siehe diesen Diskussionsbeitrag: http://forum.lighttpd.net/topic/59#6369

P. S. Mercurial und Lighty funktioniert hingegen prächtig: http://www.rootforum.org/wiki/Mercurial ... nd_FastCGI

[daemotron]

Innerhalb kontrollierter Umgebungen oder bei beschränktem Nutzerkreis würde ich auch ssh+svn nehmen - schon allein um den bremsenden Overhead für's Wrappen ins HTTP-Protokoll zu sparen. WebDAV ist bei Subversion halt für öffentliche Repositories interessant, oder wenn man hinter einer restriktiven Firewall sitzt. Zu guter letzt erleichtert WebDAV natürlich auch die Authentifizierung gegen einen großen Userpool (LDAP o. ä.) - das kann bei SSH ein bisschen frickelig werden (geht aber mittlerweile dank LPK-Patch auch ganz gut).

[Roger Wilco]

Bei uns kann man das schon als kontrolierte Umgebung sehen lästig ist es nur, weil man immer den sshd auf Port 443 laufen lassen muss

Das ist mit sslh kein großes Problem, wenn man den HTTPS Port trotzdem nutzen will.

Mal davon abgesehen würde ich heutzutage keinen neuen Subversion Server mehr aufsetzen. Meiner Meinung nach haben verteilte Versionskontrollsysteme (Mercurial, Git, …) einfach zu viele schöne Features, als dass man diese nicht nutzen wollen würde.

[daemotron]

Mal davon abgesehen würde ich heutzutage keinen neuen Subversion Server mehr aufsetzen. Meiner Meinung nach haben verteilte Versionskontrollsysteme (Mercurial, Git, …) einfach zu viele schöne Features, als dass man diese nicht nutzen wollen würde.

Das ist wohl mehr eine Frage der Prozesse... zumindest in professionellen Projekten bedeutet es schon eine Umstellung der Arbeitsweise, wenn jeder Entwickler einen Klon des Repositories selbst verwaltet. Je größer ein Team, desto eher lohnt sich der verteilte Ansatz - damit bekommt aber die Rolle des Repository Maintainers eine neue Bedeutung und ein verändertes Aufgabenfeld.

[Roger Wilco]

Das ist wohl mehr eine Frage der Prozesse... zumindest in professionellen Projekten bedeutet es schon eine Umstellung der Arbeitsweise, wenn jeder Entwickler einen Klon des Repositories selbst verwaltet.

Keine Frage, wenn entsprechende Prozesse schon vorhanden sind und praktiziert werden, würde ich auch nicht nur um des Wechselns Willen das Versionskontrollsystem wechseln. Jedoch kann man diesen scheinbaren Nachteil (kein zentrales autoritatives Repository vorhanden) durch Konventionen oder eben entsprechende Prozesse auch mit verteilten Versionskontrollsystemen erreichen.