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.

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.

Gruss,
Stephan

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)