SVN mit Remote Workspace

  • SVN mit Remote Workspace

    Moin :)

    ich habe auf meinem Server svn eingerichtet, so weit so gut.

    Als client benutze ich das ZendStudio.
    Jetzt werden logischerweise die Daten aus dem Repo. auf meinen lokalen Rechner heruntergeladen.

    Mein Problem, oder besser gesagt, schwer lösbare Aufgabe :) ist, dass auf meinem client ungern einen Webserver installieren möchte.

    Das Ziel sollte sein, auf einem Remote Server mich mit dem SVN Repo. zu verbinden und dort zu arbeiten.


    Momentan umgehe ich das mit einem Tool, welches alle lokal geänderten Daten automatisch auf den ftp hochlädt, so dass nur eine geringe Verzögerung entsteht.
    Ich finde das eine sehr unschöne Lösung.

    Vielleicht hat ja einer von euch eine Lösung parat.
    Bzw. wie arbeit ihr mit SVN (in Bezug auf PHP).

  • Hm. Doofes Konzept. Der Gedanke von svn ist ja gerade, dass man an lokalen Kopien arbeitet, die commited und diese dann aus dem repository auf diverse server (testing, development, live usw.) übertragen werden. Du willst eigentlich, so wie du zu arbeiten scheinst, auf svn verzichten ;)

    Du könntest Deine Methode aber dennoch recht bequem mit einer IDE wie z.B. Coda ermöglichen. Einfach auf dem Server per SFTP arbeiten und per SSH von dort die Änderungen committen. Durch den Rücken in die Brust... :)

  • vince schrieb:

    Bzw. wie arbeit ihr mit SVN (in Bezug auf PHP).

    Philipp beschreibt das Verfahren genau richtig.

    Dabei habe ich mir auch nochmal Gedanken über das Release Management gemacht und ein separates Thema aufgemacht: Release Management

    Nochmal als Anmerkungen: Bei uns arbeiten die Entwickler natürlich auch lokal und commiten ihre Änderungen dann "funktionierend" ins trunk.

  • Ok, das war ein bischen falsch beschrieben.

    Ich möchte einfach nur den Punk umgehen, dass ich auf meiner lokalen Maschine ein webserver installieren muss.
    Vor allem in Bezug auf die Datenbank möchte ich den User nicht für alle Hosts öffnen.

    Die Idee ist dann einfach, dass alle die an dem Projekt arbeiten auf dem FTP ein "Auslieferungsverzeichnis" erhalten.

    z.B
    "/var/ww/htdocs/user1"
    "/var/ww/htdocs/user2"
    ...

    Die Dateien bei den jeweiligen Usern sind dann, wenn jeder die commits und updates gemacht hat redundant.

    Das das der Sinn von svn ist, ist schon klar.
    Das macht auch Sinn wenn man mit Clientseitigen Programmiersprachen arbeitet, aber bei einer Serverseitigen Programmier- bzw. Scriptsprache ist das aus meiner Sicht unsicher und umständlich, da jeder die selbe Serverconfig erstmal einrichten muss.

    Kurz gesagt, wäre es wie ein lokales Verzeichnis nur dass jeder sein eigenes remote Verzeichnis hat und eigenständig am Projekt arbeiten kann.

  • Dann also weg von SVN als Transferprotokoll ;)

    Du kannst mit einem (S)FTP Programm das lokale Verzeichnis monitorn damit Dateien bei Änderungen automatisch hochgeladen werden.
    Und wenn du auf dem Online-Entwicklungsserver-Mit-Userverzeichnis alles getestet hast, machst du deinen SVN commit vom lokalen Rechner und die anderen können sich die Updates herunterladen.
    Da sie auch das Verzeichnis monitorn bewirkt ein SVN Update, dass auch ihre aktuellen Userverzeichnisse hochgeladen werden.

  • Wir haben es anders gelöst.

    Auf dem Server läuft ein Java Prog, was immer die aktuelle Rev. des Repos checkt.
    Wenn es Veränderungen gibt, checkt das Programm einfach den Entwicklungsordner von uns aus.


    So kann man local an den Dateien arbeiten und beim commiten wird dann einfach das Repo mit dem ftp gesynct.

    Muss halt bei Änderungen jeder sein eigenes branch erstellen. Aber da wir momentan erstmal nur zu zweit sind, ists ja kein Problem.

  • Also bei uns ist das optional, jeder hat seine Lokale Entwicklungsumgebung, da kann er machen was er will, dann hat jeder eine Samaba-Freigabe auf dem Preview-Server und sein eigenen VHost. Ich mounte mein laufwer via "jd" und mein VHost (jd.preview.com) leitet genau in meine Freigabe. Somit habe ich auch einen Remote-Workspace... und wir machen alles via SVN ohne FTP gezappel.
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • Wenn man im Intranet arbeitet, ist das natürlich ein Vorteil.

    Den Weg über das FTP haben wir ja jetzt auch umgangen, da das Script Serverseitig läuft und die Daten vom SVN Repo mit dem Ordner des (V)Hosts synct.


    Am schönsten ist natürlich, wenn man lokal arbeitet.
    Aber da wir mit der DB2, dem ZendDebugger und GeoIP und anderen Pear/PECL erweiterungen arbeiten ist es ziemlich nervig, wenn jeder erstmal seinen lokalen Server so einrichten muss.

  • Das geht auch via WAN Stichwort TLS/SSL für die Sicherheit, dann hätten wir noch OpenVPN in angebot. Ist zwar nicht einfach das zu konfigurieren, aber alternativ das ganze via SSH für jeden user chrooten. Du kannst SVN auch mit Post-Scripts verpacken, das wäre auch noch ne alternative. SVN ist an sich recht mächtig, hier ist ein OpenBook da steht das alles drinne wir man das machen kann. svnbook.red-bean.com/
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.