SVN + Dropbox

ist nur für Menschen, die auf Schmerzen stehen – kann ich jetzt nach eigenen Erfahrungen überhaupt nicht empfehlen.

Hintergrund ist der, dass ein Kommilitone und ich gerade dabei sind, Studienarbeit zu schreiben. Da ich keinen privaten Server mit SVN habe und es an der Hochschule SVN nur mit Einschränkungen (50MB für’s gesamte Repo und nur über SSH auf einen langsamen Server) geht, haben wir uns dafür entschieden, eine Dropbox als Repository zu verwenden. Theoretisch funktioniert das ganz gut, ABER:

Hat man einmal den Dropbox-Syncer nicht an oder macht ausgerechnet in dem Moment, in dem jemand anders etwas hochlädt, selbst einen Commit, knallt’s. Aber richtig. Dann heißt es Working Copy neu ziehen und/oder Scherben zusammenkehren.

Macht nicht viel Spaß, man verliert Informationen und es ist einfach zum brechen.

Nicht machen. Nicht mal dran denken.

5 Gedanken zu „SVN + Dropbox

  1. OwnCloud, damit hast du deine eigene Dropbox auf deinem Webserver…
    Jedoch bietet OwnCloud eine rudimentäre Versionsverwaltung, sprich du kannst jede vorherige Version einer Datei wiederherstellen.
    Zugriffsrechte lassen sich anhand einer einfachen Benutzerverwaltung regeln.

    Das ganze benötigt nur PHP + SQLite/MySQL und ein wenig freien Platz, somit auf fast jedem Webspace hostbar

  2. Danke für den Tipp, werde ich mir merken!

    Für die Arbeit bleiben wir wohl auf der „Frickellösung“, da ich meinem Kommilitonen und mir die Umstellung auf Git nicht antun will.

  3. Es zahlt sich wirklich aus, eine moderne Versionsverwaltung wie git oder hg zu erlernen und einzusetzen. Zum einen gibt es nur ein Verzeichnis für Metadaten in der Wurzel und nicht wie bei svn eins in jedem Ordner (sehr fehleranfällig), zum anderen macht das mergen damit regelrecht Spaß. Mit svn war ist das jedesmal eine frustrierende Katastrophe. Weiterhin entfällt der Einrichtungsaufwand für kleine Mal-Eben-Projekte. Einfach im Projektordner „hg init“ eingeben und schon ist das Repository aufgesetzt.

    Zugegeben, ein Weilchen dauert die Einarbeitung schon, wenn man in den svn-Denkstrukturen gefangen ist.

    Ich persönlich verwende hg, weil ich damit dank hgweb auch ein „zentrales“ Repository bei meinem Billig-Hoster ablegen kann (python über cgi) und weil es einen Buchstaben kürzer als git ist 😉

    Übrigens kannst Du bei hg und git auch schön Dropbox einsetzen, in dem Du im gemeinsamen Ordner das „Zentral“-Repository vereinbarst, über das ihr beide eure push und pull-Operationen abwickelt. So lange ihr sicherstellt, dass nicht zwei Personen gleichzeitig push oder pull ausführen, funktioniert das tadellos.

  4. Das ist ja eine richtige Anteilnahme hier, bin ich noch gar nicht gewohnt 😉

    Git habe ich vor einem halben Jahr schon einmal angekratzt,war mir für meine kleinen Sachen zu Hause aber fast schon ein wenig zu groß. SVN oder zumindest TortoiseSVN ist vor ein paar Versionen übrigens von diesen nervigen .svn-Ordnern in allen Unterverzeichnissen der Working Copy zum Glück weggegangen. Das zählt als Argument nicht mehr 😉

    Über hg muss ich mich mal einlesen, hab momentan aber leider zu wenig Zeit, mich damit zu beschäftigen…

    Das Problem mit konkurrierenden Zugriff haben wir mittlerweile über ICQ gelöst und mit der Tatsache, dass ich eher ein Abendmensch bin.

    Quintessenz ist denke ich, dass es in Verbindung mit Dropbox (noch) keine perfekte Lösung mit „draufgesetzter“ Versionsverwaltung gibt.

Kommentare sind geschlossen.