Bei mir in der Firma auch. Problem bei Git: Es gibt effektiv keine grafischen Tools dafür, das System ist deutlich komplexer. Und der Chef entwickelt gelegentlich selber mit. Und es ist nicht so, als wenn das viel simplere svn nicht auch seine Tücken hätte.
Zu bzr: Zwar einfacher in der Benutzung, dafür meines Wissens auch keine grafischen Tools verfügbar sowie sehr langsam...
Was ist bitte an git mehr komplex als an subversion? Ich finde git extrem einfach und sehr intuitiv, weitaus mehr als subversion (habe subversion aber das letzte mal vor 2 Jahren benutzt).
Wir, und zwar weil mal in Subversion auch Dateien "locken" kann. Dies ist nötig, da wir es fast ausschließlich mit binären Dateien zu tun haben und die Locks als Diskussionsgrundlage dienen, wer gerade bei welcher Datei arbeitet. Da wir einen zentralen Server benötigen, wo die Freigabestände liegen und eh nicht parallel arbeiten können, weil binäre Dateien keinen Merge erlauben und weil Subversion gute Grafische Frontends hat, nutzen wir es und nicht git/hg/bzr
Auch wenn es abgedroschen klingt kann man es nicht oft genug betonen: "Für jede Arbeit soll man das dazu passende Werkzeug verwenden."
Es gibt Anwendungsfälle, da ist Git (oder ein anderes verteiltes Versionsverwaltungssystem) von Vorteil in anderen eher soetwas wie SVN (zentrales Versionsverwaltungssystem). Den sattsam bekannten Googletalk von Linus' fand ich einfach nur peinliche Selbstbeweihräucherung und Ignoranz anderer Arbeitsabläufe als dem seinen.
Git ist innerhalb einer klar definierten überschaubaren Gruppe von Entwicklern, welche sich gegenseitig hinreichend gut kennen, super einsetzbar. Dieses Modell kann durch hierarchische Kaskadierung (Subsystemmaintainer als Vorfilter) in gewissem Maße auf größere Gruppen, wo nicht jeder jeden kennt einigermaßen skaliert werden - solange die Hierarchie klar ist.
Wenn es aber darum geht einen großen losen informellen Haufen gelegentlich beitragender Benutzer zu kordinieren (also Softwareverwaltung wie in einem Wiki) ist ein zentrales Versionsverwaltungssystem klar im Vorteil, weil der ganze Overhead ala "Wohin muss ich mich wenden (Pullrequest) und wo muss ich nachschauen (Pull)" größtenteils wegfällt.
Ich finde es immer wieder lustig, dass Git angeblich nur für kleine, überschaubare Gruppen geeignet sein soll.
Ohne jetzt selbst Erfahrung mit sehr großen Projekten haben zu müssen, beweist Git offensichtlich jeden Tag, dass es sehr, sehr gut skaliert. Der Linux-Kernel ist wohl eines der größten (in jeglicher Hinsicht) Projekte... Und da scheint es ja irgendwie zu gehen...
Vielleicht sollte man sich nicht nur von seinen eigenen Erfahrungen und gewohnten Arbeitsabläufen ausgehen... Hinter dem Berg scheint es zumindest in diesem Fall noch ganz andere Dinge zu geben...
Ich finde Leute wie dich lustig, die blind Antgworten geben, ohne mal den Text des Posters gelesen oder verstanden zu haben. Er hat nämlich absolut Recht. Es gibt nicht so viele Leute, die bei GIT committen dürfen:-)
Darüberhinaus finde ich nicht, dass der Linuxkernel ein besonders großes Projekt ist. Ich bin für 6 Repositorys in unserer Firma verantwortlich, das größte SVN Repository hat 30GB. Nun gut da sind auch einige Binärdateien eingecheckt, aber trotzdem liegt 10-20x soviel Code wie im Linuxkernel.
>>>Hinter dem Berg scheint es zumindest in diesem Fall noch ganz andere Dinge zu geben.
>> Es gibt nicht so viele Leute, die bei GIT committen dürfen:-)
Jeder kann committen so oft er will. Im Gegensatz zu SVN, denn meist ist der Checkout-Vorgang anonym und ohne Schreibrecht (bei code.google.com oder wo auch immer). Selbst wenn man da nur für sich was ändern will, kann man das nicht committen (es sei denn, man macht parallel dazu ein "git init").
Der Workflow von git gefällt mir da viel besser: Erst klonen, und wenn man was sinnvolles beizutragen hat, pullrequest an jemanden, der im fest Projekt ist. Wenn da regelmäßig was bei rüber kommt, kann man dann im Nachhinein noch SSH-Zugänge verteilen (damit der Interessent dann in ein Repo pushen kann, aus dem der Rest die Änderungen zieht).
Ich hab mich w2ohl falsch ausgedrückt. Es ging ja drum, dass der Linux Kerfnel ein riesen Projekt mit massig Entwicklern sei. Diesbezüglich ist mein Satz zu verstehen, es gibt nicht viele Entwickler, die beim Linuxkernel committen dürfen:-)
>>>Der Workflow von git gefällt mir da viel besser
Ja dir gefällt es so, es gibt aber auch andere Einsatzzwecke und da ist SVN Style besser. Im Firmenumfeld habe ich jedenfalls noch nie git gesehen:-)
Von Anonymous Coward am Do, 5. November 2009 um 18:54 #
Das ist haarsträubender Blödsinn. Wohin man sich wenden muss, ist ohnehin klar: es gibt einen Branch, aus dem das Release erzeugt wird, bei Linux ist das beispielsweise Linus' Branch, und das Ziel ist logischerweise, dass der Entwickler irgendwann seinen Code in diesen Branch kriegt. Und wo man Pullen muss, wird einem ja durch die Pull-Requests mitgeteilt.
svn ist aber ganz praktisch, wenn es keinen einzelnen Maintainer für etwas gibt. Oder anders gesagt, svn erleichtert es, ein zentrales Repository zu haben.
Gerade bei kleinen Gruppen (wie sie in den meisten Firmen vorherschen) ist ein zentrales Repository viel besser. Ich kann den verteilten Systemen nichts abgewinnen - ausser das Mercurial deutlich schneller ist als svn wenn das Respository mehere Gigabyte gross wird weil auch sämtliche Entwicklungswerkzeuge (compiler und die MSDN) darain sind.
Aber du kannst in einer kleinen Firma einen Rechner hernehmen und sagen, dass die Entwickler bitte immer auf diese Maschine pushen sollen. Dann hast du immer eine Maschine, auf der meinetwegen die Test laufen können und jeder Entwickler kann trotzdem noch wild auf seiner Maschine committen und branchen und mergen wie er will.
Von Fürst von Metternich am Do, 5. November 2009 um 23:12 #
Bei Git kannst du so viele Repositories anlegen, wie du lustig bist. FTP reicht und das liefert auch eine komplexe Rechteverwaltung... Inwiefern der Aufwand nicht den Nutzen übersteigt ist eine andere Frage.
Ach ne jetzt kommt wieder so ein Hobbybastler und verzapft seinen Unsinn.
Junge dein gitosis kannst du für deine LAN Parties nutzen, aber das wars dann auch schon. Wenn ich von ordentlicher zentraler Rechteverwaltung rede, dann meine ich damit Active Directory/LDAP und kein rumeditieren von Textfiles:-) Du möchtest ja z.B. einem Frelancer/Diplomanden usw z.B. automatisch nach 6 Monaten wieder das Recht nehmen, ohne das du hier nochmal rumeditieren musst und ne LDAP/AD Anbindung hast du bei SVN nun ganz einfach:-)
Bitte überlasst solche Diksussionen doch Leuten, die Ahnung von der Thematik haben.
Weil es sehr viele Tools gibt die SVN besser/eher unterstützen als andere SCMs. Da ist die Unterstützung einfach breiter.
In Firmen möchte man zudem oft einen Single Point of Truth. Das ist einfacher handhabbar. Eine Umstellung macht hier zudem oft wenig Sinn, wenn SVN bereits gut genutzt wird und es keinen akuten Handlungsbedarf gibt.
Du meinst also, dass subversion noch weit verbreitet ist liegt an der Lernresistenz und Trägheit seiner Benutzer? In Ordnung, waber warum peinlich, ist diese Wertung nicht ein wenig selbstgerecht? Gewohnheiten legt man nunmal nicht so schnell ab, auch schlechte nicht. Das ist menschlich, sollte man zumindest tolerieren können.
Ich mag git aber ich könnte mir z.B. das gesamte {Free,Net,Open}BSD base-system nicht wirklich darin vorstellen. Torvalds sagt ``split it'' aber sobald man ein solch grosses Projekt splittet wird die Synchronisation von mehreren OS-Komponenten so gut wie unmöglich. Und wenn man einfach alles in ein riesiges git-repo packt.. dann wird ein git-clone mit der Zeit schrecklich gross. Und man will eigentlich nicht immer die gesamte History.. aber ein `purer' checkout geht ja nicht mit git.
Wie gesagt: ich mag git aber ich kann Torvalds' Argumentation nicht gänzlich nachvollziehen.
SVN braucht ziemlich genau (etwas mehr) als den doppelten Platz der eigentlichen Dateien, da immer Kopien gehalten werden. D.h. in ganz schön vielen Repositories ist das komplette Git-Repository kleiner als ein einfacher SVN-Checkout... Und wenn du das Git-Protokoll benutzt, ist ein Clone sehr, sehr schnell passiert. Da würde ich nicht drauf wetten, dass ein SVN-Checkout per üblichem WebDAV in jedem Fall schneller geht und kleiner ist...
Wer in der Lage ist, das Git-Protokoll zu nutzen, kann auch das SVN-Protokoll nutzen. WebDAV bietet sich da an, wo die Firewall alles außer HTTP(S) grundsätzlich sperrt. Da geht aber auch kein git://
Also ich habe aufgegeben an manchen projekten mit git mitzuarbeiten. Nur um ein file zu ändern muss ich 700MB runterladen, anstatt nur das eine subverzeichnis so bei bei svn, was ganze 327kb wäre (gerade geschaut). Jetzt werden halt wieder wie in der Steinzeit patches verschickt.
(Und das branch Konzept von git scheint auch niemand zu verstehen, wenn selbst git power user immer wieder aus versehen ganze branches (natürlich die stabilen produkt versionen) vom server löschen.).
git clone git://git.videolan.org/vlc.git --depth 1 ist so was wie ein "einfaches checkout" referenz http://wiki.videolan.org/Git#Setting_up_.22git_up.22_.28Tip.29 und http://www.kernel.org/pub/software/scm/git/docs/git-clone.html
Na ja CVS würde ich bezüglich Speed auch nicht anfassen. Oder war das schon OpenCVS? Bei den Zeiten würd mich aber schon interessieren wieviel Daten da im update/checkout betroffen sind. Die REpo Grössen sagen gar nichts wenn man nicht weiss ob da seit Adam und Eva alles drin hängt.
Also ich nutze seit einiger Zeit mit absoluter Begeisterung den pkgsrc git-mirror (bereitgestellt von den DragonflyBSD Leuten).
Also echt der Hammer* ! Der Sync geht sau schnell (kein vergleich zu cvs) und auch noch sehr Resourcensparsam. Ich hab mein pkgsrc auf einer nslu und auch der 1. sync ging ratzfatz...!
Hallo, da ich kein Entwickler bin und nur ab und zu mal ein Projekt zum Compilen auschecke .... wo ist der große Unterschied zwischen beiden Systemen? Was gibt es vor Vor- und Nachteile?
- Subversion ist ein zentrales Repository, d.h. du hast / brauchst einen Server, auf dem "die Wahrheit" liegt. Den kannst du einfach sichern und du bist sicher GIT und Co. sind die neueren dezentralen Repositories, d.h. jeder Rechner hat seine eigene Versionierunshistorie und man merged nach Lust und Laune mit den anderen. Schöner an GIT ist also z.B. dass du (eigene) Versionen haben kannst, ohne diese gleich auf einem Server einchecken zu müssen (und den build zu killen). - Das Tooling (graph. Clients und Integration in IDEs und die Doku von Subversion ist IMHO besser; auch kommt es mir einfacher zu Handhaben vor.
Zu bzr: Zwar einfacher in der Benutzung, dafür meines Wissens auch keine grafischen Tools verfügbar sowie sehr langsam...
Wie wäre es mit "alle die damit zufrieden sind"?
Weil SVN-Branches mit Seilen nicht zurechtkommen.
Es gibt Anwendungsfälle, da ist Git (oder ein anderes verteiltes Versionsverwaltungssystem) von Vorteil in anderen eher soetwas wie SVN (zentrales Versionsverwaltungssystem). Den sattsam bekannten Googletalk von Linus' fand ich einfach nur peinliche Selbstbeweihräucherung und Ignoranz anderer Arbeitsabläufe als dem seinen.
Git ist innerhalb einer klar definierten überschaubaren Gruppe von Entwicklern, welche sich gegenseitig hinreichend gut kennen, super einsetzbar. Dieses Modell kann durch hierarchische Kaskadierung (Subsystemmaintainer als Vorfilter) in gewissem Maße auf größere Gruppen, wo nicht jeder jeden kennt einigermaßen skaliert werden - solange die Hierarchie klar ist.
Wenn es aber darum geht einen großen losen informellen Haufen gelegentlich beitragender Benutzer zu kordinieren (also Softwareverwaltung wie in einem Wiki) ist ein zentrales Versionsverwaltungssystem klar im Vorteil, weil der ganze Overhead ala "Wohin muss ich mich wenden (Pullrequest) und wo muss ich nachschauen (Pull)" größtenteils wegfällt.
Ohne jetzt selbst Erfahrung mit sehr großen Projekten haben zu müssen, beweist Git offensichtlich jeden Tag, dass es sehr, sehr gut skaliert. Der Linux-Kernel ist wohl eines der größten (in jeglicher Hinsicht) Projekte... Und da scheint es ja irgendwie zu gehen...
Vielleicht sollte man sich nicht nur von seinen eigenen Erfahrungen und gewohnten Arbeitsabläufen ausgehen...
Hinter dem Berg scheint es zumindest in diesem Fall noch ganz andere Dinge zu geben...
Evtl. solltest du den Text deines Vorposters nochmals durchlesen.
Ich finde Leute wie dich lustig, die blind Antgworten geben, ohne mal den Text des Posters gelesen oder verstanden zu haben.
Er hat nämlich absolut Recht. Es gibt nicht so viele Leute, die bei GIT committen dürfen:-)
Darüberhinaus finde ich nicht, dass der Linuxkernel ein besonders großes Projekt ist. Ich bin für 6 Repositorys in unserer Firma verantwortlich, das größte SVN Repository hat 30GB. Nun gut da sind auch einige Binärdateien eingecheckt, aber trotzdem liegt 10-20x soviel Code wie im Linuxkernel.
>>>Hinter dem Berg scheint es zumindest in diesem Fall noch ganz andere Dinge zu geben.
Jetzt kläre uns doch mal auf:-)
Jeder kann committen so oft er will. Im Gegensatz zu SVN, denn meist ist der Checkout-Vorgang anonym und ohne Schreibrecht (bei code.google.com oder wo auch immer). Selbst wenn man da nur für sich was ändern will, kann man das nicht committen (es sei denn, man macht parallel dazu ein "git init").
Der Workflow von git gefällt mir da viel besser: Erst klonen, und wenn man was sinnvolles beizutragen hat, pullrequest an jemanden, der im fest Projekt ist. Wenn da regelmäßig was bei rüber kommt, kann man dann im Nachhinein noch SSH-Zugänge verteilen (damit der Interessent dann in ein Repo pushen kann, aus dem der Rest die Änderungen zieht).
Ich hab mich w2ohl falsch ausgedrückt. Es ging ja drum, dass der Linux Kerfnel ein riesen Projekt mit massig Entwicklern sei. Diesbezüglich ist mein Satz zu verstehen, es gibt nicht viele Entwickler, die beim Linuxkernel committen dürfen:-)
>>>Der Workflow von git gefällt mir da viel besser
Ja dir gefällt es so, es gibt aber auch andere Einsatzzwecke und da ist SVN Style besser. Im Firmenumfeld habe ich jedenfalls noch nie git gesehen:-)
Gerade bei kleinen Gruppen (wie sie in den meisten Firmen vorherschen) ist ein zentrales Repository viel besser. Ich kann den verteilten Systemen nichts abgewinnen - ausser das Mercurial deutlich schneller ist als svn wenn das Respository mehere Gigabyte gross wird weil auch sämtliche Entwicklungswerkzeuge (compiler und die MSDN) darain sind.
Von daher, wenn man keine Ahnung von sowas hat einfach ruhig sein.
Junge dein gitosis kannst du für deine LAN Parties nutzen, aber das wars dann auch schon.
Wenn ich von ordentlicher zentraler Rechteverwaltung rede, dann meine ich damit Active Directory/LDAP und kein rumeditieren von Textfiles:-)
Du möchtest ja z.B. einem Frelancer/Diplomanden usw z.B. automatisch nach 6 Monaten wieder das Recht nehmen, ohne das du hier nochmal rumeditieren musst und ne LDAP/AD Anbindung hast du bei SVN nun ganz einfach:-)
Bitte überlasst solche Diksussionen doch Leuten, die Ahnung von der Thematik haben.
Würd ich ja gerne, aber da muss man so selten versionieren.
>> Bitte überlasst solche Diksussionen doch Leuten, die Ahnung von der Thematik haben.
Genau darum solltest du mal ruhig sein, und lieber wieder für den Granx Prix üben, Lordi.
In Firmen möchte man zudem oft einen Single Point of Truth. Das ist einfacher handhabbar.
Eine Umstellung macht hier zudem oft wenig Sinn, wenn SVN bereits gut genutzt wird und es keinen akuten Handlungsbedarf gibt.
Fashion victim.
Wie gesagt: ich mag git aber ich kann Torvalds' Argumentation nicht gänzlich nachvollziehen.
SVN braucht ziemlich genau (etwas mehr) als den doppelten Platz der eigentlichen Dateien, da immer Kopien gehalten werden.
D.h. in ganz schön vielen Repositories ist das komplette Git-Repository kleiner als ein einfacher SVN-Checkout...
Und wenn du das Git-Protokoll benutzt, ist ein Clone sehr, sehr schnell passiert. Da würde ich nicht drauf wetten, dass ein SVN-Checkout per üblichem WebDAV in jedem Fall schneller geht und kleiner ist...
WebDAV bietet sich da an, wo die Firewall alles außer HTTP(S) grundsätzlich sperrt. Da geht aber auch kein git://
(Und das branch Konzept von git scheint auch niemand zu verstehen, wenn selbst git power user immer wieder aus versehen ganze branches (natürlich die stabilen produkt versionen) vom server löschen.).
referenz http://wiki.videolan.org/Git#Setting_up_.22git_up.22_.28Tip.29 und http://www.kernel.org/pub/software/scm/git/docs/git-clone.html
http://wiki.freebsd.org/GitConversion
* Box: Single Opteron, 2Gb Physical, zfs, 256G virtual, FibreChannel Raid5 (3T space)
Conversion results: (Note repack used ~ 10GB Swap)
* /doc - Convert Time: 23Mins, Git Repo size: 63M (after repack), CVS Repo Size: 234M
* /src - Convert Time: ~6h20m, Git Repo Size: 495M (before repack 2.2G, repack time ~18hours), CVS Repo Size: 2.3G
* /ports - Convert Time: ~31h, Git Repo Size: 347M (before repack 3.9G, repack time ~52hours), CVS Repo Size: 1.2G
Operation CVS Git
checkout/clone 4:55.45 6:18.69
update/checkout 7:26.40 0:28.66
diff (entire src repo) 2:23.74 0:05.27
Bei den Zeiten würd mich aber schon interessieren wieviel Daten da im update/checkout betroffen sind. Die REpo Grössen sagen gar nichts wenn man nicht weiss ob da seit Adam und Eva alles drin hängt.
Also echt der Hammer* !
Der Sync geht sau schnell (kein vergleich zu cvs) und auch noch sehr Resourcensparsam.
Ich hab mein pkgsrc auf einer nslu und auch der 1. sync ging ratzfatz...!
Seitdem bin ich wirklich beeindruckt von git
- Das Tooling (graph. Clients und Integration in IDEs und die Doku von Subversion ist IMHO besser; auch kommt es mir einfacher zu Handhaben vor.
gruß Micha