Lokales SVN aufsetzen in 3min

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ich bin erst seit etwa einem halben Jahr von git/hg mehr angetan als svn, welches ich seit mehreren Jahren für vieles benutzt hab, unter anderem wegen:

    zerm schrieb:

    Ich persönlich bevorzuge immernoch SVN aus den folgenden, einfachen Gründen:
    - Zentral: Ich arbeite nicht am Linux-Kernel oder mit 1000 anderen Nutzern. Eine zentrale Verwaltung reicht mir da.

    git ist genau genommen noch "zentraler", da du nicht einmal ein separates checkout-Verzeichnis brauchst. Mit "git init" dein momentanes Arbeitsverzeichnis in ein Repo verwandeln und fertig, deine working copy ist dein Repo. Solltest du irgendwann später das Ding doch serven wollen kannst du ganz einfach daraus einen Klon erstellen und via http/ssh/git Protokoll serven.

    zerm schrieb:

    - Dadurch ist der Speicheraufwand auch deutlich geringer, Zugriffskontrollen sind leicht umzusetzen

    Ich habe kürzlich eines meiner svn-Repos nach git umgewandelt (inkl. Import der commit-history und allem). Das svn repo war 17.x MB gross, das git Repo ist 5.4 MB gross. Ob das wegen dem Import optimiert wurde oder das generell der Fall ist kann ich nicht sagen.

    zerm schrieb:

    - SVN läuft perfekt, einfach und sicher über HTTP am Apache. So kann ich ohne irgendwelche Probleme von überall auf meine Repositories zugreifen und muss so gut wie keine zusätzliche Software installieren; kein ssh etc. für die Nutzer

    Dasselbe mit git. Ich habe (und nutze noch immer) svn via SSH, weil mein Server nur diesen Port offen hat, klappt wunderbar, klappt mit git genauso wunderbar. ;)

    zerm schrieb:

    - Höhere Verbreitung (noch?): Die meissten kennen SVN und kommen auf Anhieb damit klar

    Die Verwendung der Hauptfeatures von git läuft ja ziemlich genau gleich ab. Ok, "clone" statt "checkout" und "pull" statt "update" muss man sich merken, sonst, "status", "diff", "add/mv/rm", "commit -m" (gefolgt von "push" bei git), alles dasselbe. Und es gibt gute Cheat-Sheets da draussen.

    zerm schrieb:

    - Git/Hg haben ein paar nette Features, mir ist das aber alles zu kompliziert. Für OpenSource-Entwicklung an grösseren Projekten ist es wirklich perfekt, aber mit den ganzen Heads und Pulls und Konzepten, die man verstehen muss (und bei Nichtbenutzung nach kurzer Zeit wieder vergessen hat) stellt es für mich keinen Vorteil dar.

    Das ganze Zeugs mit branches und merges hab ich mir noch nicht genau angesehen. Auf github.com z.B. läuft das alles wunderbar via Webinterface, falls das jemand probieren will. Und bei bitbucket.com kann man seit kurzem unbeschränkt viele private Mercurial (hg) Repos erstellen, also wenn jemand keinen eigenen Server hat, anschauen! Die FAQs der beiden genannten Seiten sind ebenfalls super, da ist man sofort drin. Google Code hinkt da leider noch etwas hinten drein.

    Ich für mich behalte die meisten svn-Repos wohl noch, ist nicht so dass svn jetzt viel schlechter ist als git (oder hg), aber insbesondere kleinere, private Projekte manage ich mit git, da ich damit nur eine Kopie brauche, bei svn ist immer, auch lokal, das checkout-Repo und die working copy vorhanden. Es sind wirklich nur 2 Terminal-Befehle und man hat ein Repo aus einem Projekt erstellt: git init && git add *. :)


    Edit
    Zum Thema Speicheraufwand hab ich im Link von klausel gerade gefunden:
    For example the Mozilla repository is reported to be almost 12 GiB when stored in SVN using the fsfs backend. Previously, the fsfs backend also required over 240,000 files in one directory to record all 240,000 commits made over the 10 year project history. This was fixed in SVN 1.5, where every 1000 revisions are placed in a separate directory. The exact same history is stored in Git by only two files totaling just over 420 MiB. SVN requires 30x the disk space to store the same history.
    Widgetschmie.de • Life is too short for gadgets

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pascal ()

  • Mhh ja ich überlege ja schon immer, vielleicht doch mal auf git umzusteigen weil alle immer so zufrieden sind etc.
    Ich habe jetzt hier und hier Anleitungen gefunden, wie man so ein Repository über (WebDAV) apache per HTTP zugänglich machen kann und mit gitosis sehr genaue Zugriffskontrollen umsetzen kann. Wenn es jetzt noch ein schönes Webfrontend dafür gäbe, wäre ich fast geneigt, das mal zu probieren. Vielleicht den git-plugin mal für trac probieren. Schade, dass das Webfrontend von github nicht frei ist...(oder?)

    EDIT
    Ui, von gitorious gibs das ganze Webfrontend als OpenSource. Das sieht ja neckisch aus..
    C++

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zerm ()