Hi,
On Wed, March 2, 2011 10:43, streber wrote:
ich bearbeite Dateien auf meinem VServer via scp.
Scp ist fuer die Installation ja erstmal ok.
Hmm. Wieso bearbeitest Du die Dateien auf dem Server?
Hast Du keine lokale Kopie (z.B. auf Deinem PC oder Laptop) wo Du alles erst mal ausprobierst?
Nun möchte ein weiterer Entwickler L/S-Zugriff auf ein Verzeichniss haben. Wie stellt man da am besten an? Ohne FTP.
Warum braucht der Zugriff auf das Verzeichnis? Und dann noch schreibend?
Ich hab erstmal einen neuen User angelegt, mittels dem kann die Person schonmal lesen (warscheinlich aber alle Verzeichnisse, das ist aber OK, ich vertraue der Person).
Ist ja an sich erstmal lobenswert dass Du Freunde hast. Hat aber mit Entwickeln nix zu tun.
Schreibzugriff hab ich für eine einzelne Datei mittels 775er Recht zugelassen was funktioniert hat. Was sicher nicht der beste Weg ist.
Ist es nicht. Ein kleiner Fehler und einer von Euch beiden hat keinen Zugriff mehr. Die Rechteverwaltung wird bald mehr Kopfschmerz machen als eine richtige Loesung aufzusetzen.
Ich hab kurz versucht mit dem Paket scponly ans Ziel zu gelangen was an der Meldung: "equivalent of ld.so" scheiterte (bei Recherchen viel auf das es kaum Doku zu scponly unter Debian gibt und das es seit 2008 scheinbar auch keine neuen Einträge gibt.)
Das es seit 2008 nix neues gibt liegt daran, dass scponly einfach mal stabil ist. Ohne den exakten Output kann ich Dir leider nicht sagen was das Problem ist. Bei mir geht scponly prima (Debian).
Ich wuerde Dir empfehlen Dich mal mit einem Versionskontrollsystem anzufreunden. Das ist schon eine gute Idee, wenn man alleine entwickelt (man hat reichlich Backups die man bei Bedarf auch vergleichen kann). Wenn man zu zweit entwickelt ist es einfach mal Pflicht ("hab ich gestern nicht in Zeile x ein y gemacht? Warum ist das heute weg?").
Die Vorgehensweise ist dann ganz einfach: Ihr beide entwickelt jeweils in einer lokalen Kopie (im Slang: "working copy") in der auch erstmal gruendlich getestet werden kann. Dann wird es eingecheckt und der andere kann es sich bei Bedarf ziehen und mit seinen eigenen Aenderungen mergen ("moerdsch'n"). Wenn eine neue Version hinreichend stabil ist gibt es zwei Varianten sie auf den Server zu bekommen - entweder hat der Server auch nur eine working copy und Du machst einen checkout/update oder Du kopierst den Inhalt deiner working copy per scp auf den Server. Ein netter Nebeneffekt: die Administration bleibt bei einer Person und damit ist auch klar wer es kaputt gemacht hat wenn es mal nicht geht (das ist nicht boese, sondern erleichtert die Diagnose).
Es spricht auch nix dagegen das zentrale Repository auf dem selben Server zu speichern, der auch das Ziel der Entwicklung ist - nur halt in einem anderen Verzeichnis.
Du hast die Wahl zwischen vielen Systemen, die alle ihre Vor- und Nachteile haben.
Finger weg von kommerziellen Systemen: die sind entweder grottenschlecht (MS Source Safe) oder sehr teuer (Clearcase, etc.).
CVS - der Klassiker, wird nicht mehr weiterentwickelt. Ist relativ einfach aufzusetzen, hat aber viele Nachteile. Macht Probleme wenn Entwickler unterschiedliche Systemaccounts haben. War mal das Standardsystem, wird aber nur noch von einigen aelteren Projekten eingesetzt. Ignoriere es bitte, Du wirst nur ab und zu Verweise auf CVS sehen (meistens im Kontext von "im Gegensatz zu CVS funktioniert hier XYZ").
SVN (Subversion) - wenn auf dem Server schon Apache laeuft ist das sehr einfach aufzusetzen: installier einfach die Pakete fuer das Subversion-Apache-Modul und dann bau Dir Dein Repository. Die Doku ist Klasse. Es ist einfach zu administrieren und einfach zu verstehen. Deine Entwickler brauchen nicht unbedingt einen echten Account, sondern muessen nur in der Passwort-Datei von SVN stehen. Ist heute einer der Quasi-Standards (z.B. KDE und viele andere Projekte).
SVK - gut zur Umgewoehnung auf dezentrale Tools, setzt auf SVN auf.
Git - dezentrales Tool, was fuer die Entwicklung des Linux-Kerns entwickelt wurde. Ist heute eines der Standard-Tools. Keine Ahnung wie man es aufsetzt - ich benutze bisher (immernoch) SVN. Die Konzepte hinter dezentralen Tools sind etwas schwierig zu verstehen - sie skalieren aber besser auf viele Entwickler.
Mercurial - ebenfalls dezentral, streitet sich mit Git um die Vorherrschaft in diesem Feld.
Es gibt noch einige mehr, aber mit SVN, Git oder Mercurial machst Du keine Fehler.
Konrad