Login
Newsletter
Werbung

Thema: Git-Projekt startet Nutzerumfrage

27 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von SVN-User am Mo, 1. September 2008 um 10:49 #
Ich habe nie verstanden, wieso Linus die Git entwickelt hat, wo es doch SVN gibt? Jedenfalls seh ich keinen großartigen Unterschied zu den beiden.
  • 0
    Von Oliver am Mo, 1. September 2008 um 10:54 #
    Dann hast Du Dich wohl noch nicht näher damit auseinandergesetzt. Ein bedeutender Unterschied ist z.B., daß git einen verteilten und svn einen zentralisierten Aufbau hat. Auf youtube gibt es einen Vortrag von Linus über git.
    • 0
      Von RPR am Mo, 1. September 2008 um 11:34 #
      naja, gibt ja noch SVK mit dem SVN sehr schnell distributed wird.
      Find den Ansatz echt cool - vereint die Vorteile von beiden Ansätzen. Z.B. kann man in Arbeit / Intranet auf dem SVN arbeiten (was einfacher und schneller geht) und zuhause auf SVK (so man kein DSL oder VPN hat).
      • 0
        Von git-neuling am Mo, 1. September 2008 um 11:56 #
        ui die merges will ich nich mit svn machen.. git hat außerdem ne tolle svn-schnittstelle
        würde zum mergen eher SVN => GIT (hier merge) => SVN falls svn unbedingt sein muss..

        ja der vortrag von linus is echt sehenswert.. zumindest wenn man linus noch nie gesehen hat :)

        0
        Von Anonymer Feigling am Mo, 1. September 2008 um 14:31 #
        Git vereinigt auch beide ansätze. Du kannst es ja auch mit einem zentralen Repository nutzen und dann gibt es auch keine Probleme.
      0
      Von McRumble am Mo, 1. September 2008 um 12:31 #
      Hat hier zufällig jemand einen Vergleich oder ähnliches auf Deutsch? Ich habe erst dieses Wochenende meinen privaten SVN-Server aufgesetzt um mich da mal einzuarbeiten.

      Wär Git besser für mich geeignet? Kleines Projekt, aktuell 1 Entwickler später vielleicht. Zusätzlich müssen immer wieder Diff-Patches aus einem anderen SVN-Repository eingespielt werden.

      • 0
        Von rp- am Mo, 1. September 2008 um 12:39 #
        du hasst alleine schon den vorteil das du immer und ueberall committen kannst und nicht am server gebunden bist.
        ausserdem brauchst du auch das server repository nicht verwalten(backups,...)
        da git fuer patches designed ist, wirst du auch da mehr freude mit git haben als mit svn.

        ausserdem hat git noch viele andere schoene sachen die svn einfach fehlen.
        das einzige was bei svn meiner meinung besser ist, sind die GUI's.

        und svn mag auch leichter zu verstehen sein, ueberhaupt wenn man noch nie mit einem verteilten system gearbeitet hat.

    0
    Von Serverz am Mo, 1. September 2008 um 10:55 #
    http://www.youtube.com/watch?v=4XpnKHJAok8
    0
    Von Andreas am Mo, 1. September 2008 um 11:45 #
    Du hast git anscheinend noch nie wirklich benutzt. Ich benutz git selbst für svn, da die Tools um einiges mächtiger sind als svn.
    0
    Von gustl am Mo, 1. September 2008 um 13:29 #
    Ganz einfach:

    Git kann effizient mergen, SVN nicht.

    Wenn du 1000 Entwickler hast, und jeder schickt dir einen Patch, dann hast du das mit GIT in wenigen Minuten, wenn es Probleme gibt Stunden gemerged. Mit SVN hast du das in wenigen Stunden, und wenn es Probleme gibt Tagen gemerged.

    Das ist der Unterschied.

    Wird man natuerlich bei einem Projekt mit 3 Entwicklern nicht merken.

    0
    Von uiae am Mo, 1. September 2008 um 15:41 #
    Mach mal sowas mit svn (und das ist wirklich eines der einfachsten Dinge mit git):

    git log -p -M -C --stat **/*.txt

    Zur Erklärung:
    -p bedeutet, dass Änderungen als Patches im Log integriert angezeigt werden, -M bedeutet, dass Fileverschiebungen (Umbenennungen) erkannt werden, -C das gleiche mit Kopien und --stat integriert ein Diffstat zu jedem Commit.
    Letztendlich gibt das **/*.txt noch eine Liste von Dateien (das ** ist zsh spezifisch, kannst die Liste auch anders erhalten, das spielt für git keine Rolle).
    All das ist meines Wissens nach mit svn nicht möglich.
    svn kann, soviel ich weiß, kein log von Dateien in mehreren Pfaden erzeugen (aber genau das ist in vielen Situationen hilfreich, z.B. um sich die Änderungen im Buildsystem anzuschauen).
    svn kann meines Wissens keine Änderungen im Log anzeigen (soll glaub ich mit Scripts etc. irgendwie gehen).
    Und von diffstats hat svn afaik sowieso noch nix gehört.

    Abgesehen davon ist svn voll und ganz darauf ausgelegt, dass der Nutzer Internet zur Verfügung hat.
    Die Manpages von svn sind sehr dürftig und wenig Informativ. Die meisten holen ihre Infos dazu irgendwo aus Howtos etc. aus dem Internet.

    Bei git gehört es zum distributed Ansatz, dass es gute Manpages hat (inklusive guter Beispiele, die oft schon das abdecken, was man benötigt), denn man geht nicht davon aus, dass der Nutzer immer Zugriff auf das Internet hat.

    • 0
      Von Stephan Beyer am Mo, 1. September 2008 um 17:21 #
      Hm,

      also ich finde, es gibt ganz andere Gruende fuer Git. (Ich finde ein Diffstat zwar praktisch, koennte aber auch ohne leben.)
      Aber es scheint ja jeder eigene Lieblingsfeatures zu haben und um diese ein wenig zu sammeln,... dazu ist ja die Umfrage da :-)

      Gruss,
      Stephan

      • 0
        Von uiae am Mo, 1. September 2008 um 19:38 #
        Oh, es gibt natürlich sehr viele andere Gründe, git zu nutzen.
        Ich wollte nur ein recht einfaches Beispiel bringen, damit man sieht, wie schnell svn eigentlich an seine Grenzen stößt.
0
Von Fred am Mo, 1. September 2008 um 15:09 #
Wenn man sich gerade 20 Minuten Zeit genommen hat, die Umfrage auszufüllen um dann zu merken, dass der submit-Button JavaScript braucht und alle eingetragenen Daten bei einem Reaload der Seite futsch sind, hat man keine Lust mehr auf einen zweiten Anlauf... :(
  • 0
    Von Stephan Beyer am Mo, 1. September 2008 um 15:14 #
    Das haben wir leider erst zu spaet gemerkt, dass Survs exzessiv JavaScript braucht. Es ist ganz oben erwaehnt (NOTE), aber vermutlich hilft das nicht viel.
    (Survs wollte sich auch darum kuemmern, eine JavaScript-freie Version anzubieten, aber bisher hat sich da anscheinend nichts getan.)

    Gruss,
    Stephan

    • 0
      Von Fred am Mo, 1. September 2008 um 15:17 #
      Umm... macht den Text Rot oder fett und größer. :D
      Irgendwie überliest man das schnell.
      • 0
        Von Fred am Mo, 1. September 2008 um 15:32 #
        So, nun habe ich das noch einmal ausgefüllt und habe eine weitere Anmerkung an die Jungens von Survs. Nach dem Absenden könnte wenigstens ein kleiner Hinweis erscheinen, dass man gerade etwas getan hat. Es ist blöd, dass einfach die Startseite angezeigt wird. Wer weiß, was da einfach falsch gelaufen ist. Vielleicht war ja der Link tot und deswegen ist man nun auf der Startseite.
        0
        Von Stephan Beyer am Mo, 1. September 2008 um 21:01 #
        Danke übrigens für den Hinweis - habe ihn dem Verantwortlichen weitergeleitet, aber Survs erlaubt dort leider keine Formatierung oder HTML.
0
Von hger am Di, 2. September 2008 um 09:35 #
Ich habe hier viele Beitraege fuer git gelesen (oder eher gegen svn). Was ich gehoert habe ist Mercurial eher vergleichbar mit git (als svn). Ich nutze selbst bisher nur svn, aber kann jemand vielleicht ein paar vergleichende Worte zu Mercurial sagen (mehr git vs. hg als svn vs. hg [da habe ich schon bisschen was gefunden])? Interessiert mich eher, weil es auch nativ fuer Win verfuegbar ist und mit TortoiseHg ein (vermutlich) recht ordentliches GUI vorhanden ist.
  • 0
    Von Blackiwid am Di, 2. September 2008 um 11:33 #
    ich hab ne liste gemacht bezüglich git vs hg, aber ich hab sie nicht gerade hier, sie sind beide doch sehr änlich, zumindest wenn man sie erstmal minimal benutzt. Also nicht in die tiefe der features rein geht. prinzipiel hat hg paar sachen die eher wie in svn sind bzw vielleicht einfacher z.B. gibt es fortlaufende revisionsnummern zusätzlich zu den langen nummern. man kann also sowas in der art machen weiß grad nicht ob die syntax 100% stimmt:

    hg diff -r333:334 relativ gibt es dann sowas hg diff -r -1:-2 (glaub das war so ^^)

    in git wäre sowas eher so:

    git diff 234vd23:244adfs3 (wobei das halt beliebige teile des sehr langen revisions-ids sind)

    ja ansonten noch andere kleine änderungen in der bedienung aber das eigentlich nicht soo wichtig.

    Dann muss man sagen das hg fast komplett in python geschrieben ist und daher plattformübergreifend läuft, git in windows ist immer noch bischen schwierig bzw nciht so schnell etc. generell ist git aber schneller. und git ist deutlich besser in linux integriert.

    ein zentralles git repos aufzusetzen ist einfacher wie eins für hg aufzusetzen hatte da große probleme mit abhängigkeiten und hg hat kein eigenes protokol sondern läuft dann z.B. über http.

    Aber der größte unterschied (neben ncoh vielen anderen) warum ich jetzt git bevorzuge ist, dass branch-modell. in hg ist jeder clone also deine lokale copy ein branch, das heißt man muss praktisch bei jedem pull ein merge machen, man hat also nen haufen extra commits wo nur das mergen dokumentiert wird.

    Das ist halt gerade wenn man sich oft mit dem server syncronisiert ein bischen nervig, gut es gibt einen befehl der das automatisch macht aber man müllt schon ein bischen sein log und auch die grafisch darstellung ein wenig zu.

    Wenn man dann in gitk oder wie das hieß immer noch ein paar zusätzliche branches hat (abzweigungen die dann wieder zusammengeführt werden) kommt man dann vielleicht eher durcheinander mit den echten branches.

    Hätte ich aber nicht zuerst git gelernt hätte ich hg vielleicht bevorzugt bzw ihm noch ne größere change gegeben, man hat dann halt nicht schon vonr vorneherein erwartungen wie etwas laufen sollte ^^.

    Ein vorteil warum ich eigentlich zu hg umsteigen wollte ist eben gerade da es in python geschrieben ist udn ich mich damit gut auskenne und ich erstens davon ausgegangen bin das dafür vielleicht coolere addons(hook-scripts und anderes) geschrieben werden da man damit schneller und einfacher sachen programmieren kann bzw auch emhr leuten die sprache zugänglich ist bzw schneller erlernbar ist, bzw das ich selber solche scripte und anderes ändern oder selber schreiben kann.

    Aber ansonsten sind sie doch sehr änlich, man kann mit beiden nicht so viel falsch machen 10x besser wie svn sind sie mal beide, auch wenn man am anfang erstmal bischen zeit braucht sich umzugewöhnen bzw sich mit den befehlen vertraut zu machen (man braucht ja nicht alle aber trotzdem)

    • 0
      Von rp- am Di, 2. September 2008 um 13:49 #
      sehr schoen beschrieben!

      ich moechte noch anfuegen.
      * tortoiseHg ist noch nicht so maechtig wie man das vielleicht von tortoiseSVN gwohnt ist, fuer die meisten zusaetzlichen features kommt man um die commandline nicht herum.

      * mercurial fehlen einige features von git, zb. das bessere branching, rebase (ist in arbeit, wird aber noch dauern) und in den meisten funktionen hat man mit git noch mehr moeglichkeiten.

      * ich finde das extension system auch ein bisschen seltsam von mercurial, basis features muss man dort meist erst in der config aktivieren, bei git hast du alles was git kann.

      das was man mercurial zu gute halten muss ist die bessere unterstuetzung fuer windows.

      • 0
        Von rp- am Di, 2. September 2008 um 13:56 #
        kleine korrektur, hab gerade nachgesehn, rebase scheint jetzt in der testphase zu sein und sollte mit der naechsten release ausgeliefert werden
        http://www.selenic.com/mercurial/wiki/index.cgi/RebaseExtension

        dann sollten auch die merge verseuchten log messages ein ende haben. bleibt immer noch das branching das meiner meinung nicht so toll ist und ein paar andere sachen.

      0
      Von hger am Di, 2. September 2008 um 15:54 #
      Danke fuer die Einschaetzung.
Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung