Subversion vs. Git

[Mitglied 7643]

nicht korrekt

Ich würde zu Git tendieren.

SVN benötigt immer Server, ist im Vergleich wirklich *arschlahm*, und macht einfach keinen Spaß.

Bei Git hat man immer das gesamte Repository lokal, und kann es - optional - auf einen Server pushen (Als Hoster empfehle ich Github).
Man kann ein paar Sachen testen, ins lokale Repository pushen, und das ganze auch *offline*.
Bei SVN ist immer eine Verbindung zum Server vorausgesetzt.

Ein weiterer (Pseudo-)Vorteil ergibt sich aus dem verteilten Prinzip von Git.
Stellen wir uns vor, der Server mit dem SVN-Repository erleidet einen Festplattenschaden - ByeBye allen Änderungen. Zwar hat man zuhause auf dem Rechner noch den Code, aber das gesamte Repository ist verloren.

In Git hat jeder User lokal die gesamte History. Es ist kein Problem wenn der Server zugrunde geht oder ähnliches. Man kann einfach zu einem neuen Hoster wechseln und alles pushen - alles ist genau wie vor dem Crash, inklusive der gesamten History.

Hier noch ein bisschen Git-"Propaganda" (Wirklich zu empfehlen):
http://whygitisbetterthanx.com/

Zu guter letzt gibt es auf Youtube o.ä. noch ein Video namens "Torvalds talks to Git" oder so ähnlich. Dort hält Linux Torvalds (Erfinder von Linux ) einen Vortrag über Git.

Das ist nicht korrekt! Man kann SVN auch offline nutzen, indem man eine lokale Repository erstellt.

 

[knalli]

... SVN-Repositories lassen sich built-in syncen, das Kommando dafür ist svnsync. Google bietet auf ihrer "Google Code"-Plattform auch ganz offiziell diese Möglichkeit an, damit man beispielsweise von "woanders" dahin ziehen kann, ohne die alte History verlieren zu müssen.

Ein weiterer (Pseudo-)Vorteil ergibt sich aus dem verteilten Prinzip von Git.
Stellen wir uns vor, der Server mit dem SVN-Repository erleidet einen Festplattenschaden - ByeBye allen Änderungen. Zwar hat man zuhause auf dem Rechner noch den Code, aber das gesamte Repository ist verloren.

In Git hat jeder User lokal die gesamte History. Es ist kein Problem wenn der Server zugrunde geht oder ähnliches. Man kann einfach zu einem neuen Hoster wechseln und alles pushen - alles ist genau wie vor dem Crash, inklusive der gesamten History.

Das ist doch Quatsch. Wer einen Server ernsthaft ohne Backupstrategie fährt, dem ist nicht zu helfen. Und mit Git hat man zwar die Daten verteilt, aber das ersetzt noch lange kein "Backup". Und über SVN lassen sich auch Histories pushen, s.o.

SVN ist am verbreitesten, nicht nur in den Köpfen, sondern auch (noch) in den Tools. Wenn ein Programm VCS-Plugins hat, kann man sich sicher sein, dass SVN drin ist.

Man sollte sowohl in der Bewertung als auch in der Diskussion nicht aus den Augen verlieren, dass SVN o.ä. auf der einen und Git o.ä. auf der anderen Seite zwei verschiedene VCS-Konzepte sind. Auch Torrent-Downloads sind nicht per Definition besser als Direkt-FTP-Downloads vom Server. Wenn alle vom FTP runterladen, ist das aber schlimm für alle Beteiligten; wenn Downloads mit Pay-per-Click verbucht werden sollen, ist jedoch Torrent kein Knaller.

Für Firmen mit dem Anspruch an ein zentrales Repository gibt es dann eben ein solches. Im Übrigen: Es ist möglich, mit einem SVN-Server als Git-Client zu agieren, selbstverständlich mit einigen Einschränkungen. Die Bridge dazu stellt Git zur Verfügung (sogar built-in, wenn ich mich nicht irre).

Zum Spielen eignet sich gut Google Code (SVN und Mercurial)oder GitHub.

Die großen Pluspunkte von Git sind die Performance (weil das Repository lokal liegt, sind keine aufwendigen Serverrequests über das Netz notwendig) und bessere Merge-Fähigkeiten (alleine durch die Forks).

 

[boecko]

good bye svn

Ich bin vor 2 Wochen nach 10 Jahren CVS / SVN ( seit version 0.8) auf git umgestiegen und will nicht mehr zurück. Da ich bei uns in der Firma die Versionkontrolle überwache, war ich erstmal vorsichtig.

Warum ich nicht mehr zurück will?

• Branchen/Taggen tut nicht mehr weh. Das ist für mich mit das Killer-Feature. Und dem Web-Designer ist es leichter zu erklären, dass eine Marke nur eine Marke ist, und nicht eine Kopie unter Tags
• ich kann mir von meinen Entwickler die Sachen aus deren clones pullen und mergen, ohne mir gross den Pfad etc merken zu müssen
• Product-Versionsverwaltung lässt sich wunderschön abbilden, dank des genialen Branchings siehe http://nvie.com/posts/a-successful-git-branching-model/
• mein clone gehört mir. Das nervt mich ungemein am Macports, wenn ich zum Beispiel lokal das Portfile ändere kann ich es nirgends versionieren, da ich dort am offiziellen SVN hänge
• Staging und Amend. Was mich schon immer an SVN nervte, dass man beim Commit alles zusammensammeln muss, was man jetzt commiten will und dann was vergisst.
• Webseiten-Staging! Das wird hier schön erklärt: http://joemaller.com/990/a-web-focused-git-workflow/ Man pusht sozusagen den master-branch weiter auf den Liveserver, wodurch dort automatisch die Webseite aktualisiert wird
• nur noch EIN .git-Verzeichnis im Hauptordner des Projektes und nicht wie bei SVN in jeden Unterordner eins. Schon einmal versucht ein ganzes Typo3-Projekt im SVN zu halten? .. das macht keinen Spass. Genausowenig macht es Spass, von einen SVN-Projekt ein Verzeichnis in ein anderes Projekt zu kopieren (.svn-Ordner muss überall gelöscht werden)
• plus die viele kleinen eingebauten Features, um jemanden das Leben leichter zu machen:
  

  git stash
  git cherry-pick
  git log --graph --decorate --pretty=oneline --abbrev-commit --all (kann man sich auch als alias in die .gitconfig legen)

• GitX, gitk machen das Visualisieren des Entwicklungsbaums einfach, bei SVN breche ich mir da einen ab
• performance ist nur ein netter Nebeneffekt

Man merkt erst wie "in die Jahre gekommen" SVN ist, wenn man sich mal GIT angeschaut hat.

Grüße

Boecko

 

[boecko]

Das ist nicht korrekt! Man kann SVN auch offline nutzen, indem man eine lokale Repository erstellt.

… und dann nie mehr mit halbwegs vernünftigen Aufwand mit dem offiziellen Syncen kann.

siehe MacPorts-SVN