Er sagte: Z.B! Es gibt noch andere Gründe, die gegen die Verwendung von Git sprechen können.
So kannst du dir bei Git etwa niemals sicher sein, daß das, wie sich dir die Historie darstellt, auch die Wahrheit ist - denn Git bietet die Möglichkeit, aus dem, was war, das zu machen, was „hätte sein sollen“. Manche Leute sehen das als ein Anti-Feature an.
Git unterstützt keine VCS-IDs, während Subversion dies tut (wenn Du das doch mit Git hinbekommen solltest, sag Bescheid - es gibt Leute, die vermutlich einen Freudenschrei ausstoßen werden).
Manch einer macht geltend, daß Git eigentlich gar kein Versionskontrollsystem sei, sondern ein Werkzeug zur verteilten Zusammenarbeit. Und tatsächlich: Schaut man mit Git ins Repo-Log, sieht man gar keine Versionen/Revisionen, sondern nur Hashes. Subversion hat hier den Vorteil, numerisch vorzugehen.
Usw., usf. Es gibt viele Einwände gegen Git. Ich gehe sie nicht alle mit und ziehe persönlich Git klar vor. Aber diese arrogante Aussage „es gibt keinen Grund mehr, Subversion zu verwenden“, geht mir dann doch gegen den Strich. Am besten wäre es ohnehin, man würde zu Fossil wechseln.
Von Anonymous Coward am Fr, 5. Juni 2020 um 11:54 #
So kannst du dir bei Git etwa niemals sicher sein, daß das, wie sich dir die Historie darstellt, auch die Wahrheit ist - denn Git bietet die Möglichkeit, aus dem, was war, das zu machen, was „hätte sein sollen“. Manche Leute sehen das als ein Anti-Feature an.
Falsch, wenn Du einmal etwas in git committed und gepushed hast, kann es ohne git push -f nicht mehr geändert werden. Und -f kann man leicht serverseitig verbieten. Und serverseitig kann die Geschichte auch mit SVN umgeschrieben werden: http://oliverguenther.de/2016/01/rewriting-subversion-history/ Der einzige Unterschied ist hier also, dass git es einfach macht, die Geschichte umzuschreiben, wenn das denn gewünscht ist. Verhindern kann man es mit beiden Systemen.
Git unterstützt keine VCS-IDs, während Subversion dies tut (wenn Du das doch mit Git hinbekommen solltest, sag Bescheid - es gibt Leute, die vermutlich einen Freudenschrei ausstoßen werden).
Was soll das überhaupt sein? Keywords, also solcher Kram wie $Id$? Das ist ohnehin eine beknackte Idee. Die Aufgabe eines VCS ist es, Quellcode zu verwalten, nicht irgendwelche Variablen irgendwo einzusetzen.
Manch einer macht geltend, daß Git eigentlich gar kein Versionskontrollsystem sei, sondern ein Werkzeug zur verteilten Zusammenarbeit. Und tatsächlich: Schaut man mit Git ins Repo-Log, sieht man gar keine Versionen/Revisionen, sondern nur Hashes. Subversion hat hier den Vorteil, numerisch vorzugehen.
Wenn man eine Version kennzeichnen will, setzt man dafür einen Tag. Revisionen zu zählen bringt keinerlei echte Vorteile.
Aber diese arrogante Aussage „es gibt keinen Grund mehr, Subversion zu verwenden“, geht mir dann doch gegen den Strich.
Ist mir ehrlich gesagt egal, ob Du mich für arrogant hältst. Ich habe in dieser Sache schlicht recht, und Du weißt das auch
Es ist ganz einfach: Git hat gewonnen, Subversion ist inzwischen genauso obsolet wie SCCS.
Na endlich. Habe mich schon gefragt wann hier endlich der Erste mit Git ankommt
Was genau hat Git denn gewonen?
Die Marktherrschaft, und zwar mit Abstand. SVN braucht keiner mehr, auch wenn's sicherlich noch Leute gibt, die meinen, es zu brauchen…
Das hat Android auch, es soll aber noch leute geben die linux auf dem desktop brauchen bzw meinen es zu brauchen.
PS: Und quatsch nicht immer den Linus mist nach, es gibt sehr wohl gruende perforce oder svn zu nutzen z.b organisationsbedingt
„Organisationsbedingt“ heißt dann wohl, dass der Grund ist, dass jemand anderes (Chef) einen dazu zwingt.
Er sagte: Z.B! Es gibt noch andere Gründe, die gegen die Verwendung von Git sprechen können.
So kannst du dir bei Git etwa niemals sicher sein, daß das, wie sich dir die Historie darstellt, auch die Wahrheit ist - denn Git bietet die Möglichkeit, aus dem, was war, das zu machen, was „hätte sein sollen“. Manche Leute sehen das als ein Anti-Feature an.
Git unterstützt keine VCS-IDs, während Subversion dies tut (wenn Du das doch mit Git hinbekommen solltest, sag Bescheid - es gibt Leute, die vermutlich einen Freudenschrei ausstoßen werden).
Manch einer macht geltend, daß Git eigentlich gar kein Versionskontrollsystem sei, sondern ein Werkzeug zur verteilten Zusammenarbeit. Und tatsächlich: Schaut man mit Git ins Repo-Log, sieht man gar keine Versionen/Revisionen, sondern nur Hashes. Subversion hat hier den Vorteil, numerisch vorzugehen.
Usw., usf. Es gibt viele Einwände gegen Git. Ich gehe sie nicht alle mit und ziehe persönlich Git klar vor. Aber diese arrogante Aussage „es gibt keinen Grund mehr, Subversion zu verwenden“, geht mir dann doch gegen den Strich. Am besten wäre es ohnehin, man würde zu Fossil wechseln.
git push -fnicht mehr geändert werden. Und-fkann man leicht serverseitig verbieten.Und serverseitig kann die Geschichte auch mit SVN umgeschrieben werden:
http://oliverguenther.de/2016/01/rewriting-subversion-history/
Der einzige Unterschied ist hier also, dass git es einfach macht, die Geschichte umzuschreiben, wenn das denn gewünscht ist. Verhindern kann man es mit beiden Systemen.Was soll das überhaupt sein? Keywords, also solcher Kram wie
$Id$? Das ist ohnehin eine beknackte Idee. Die Aufgabe eines VCS ist es, Quellcode zu verwalten, nicht irgendwelche Variablen irgendwo einzusetzen.Wenn man eine Version kennzeichnen will, setzt man dafür einen Tag. Revisionen zu zählen bringt keinerlei echte Vorteile.Ist mir ehrlich gesagt egal, ob Du mich für arrogant hältst. Ich habe in dieser Sache schlicht recht, und Du weißt das auchAch komm, lies einfach das mal:
https://www.perforce.com/blog/vcs/git-vs-svn-what-difference
Keine lust mit Dir zu diskutieren, ist mir schlicht zu bloede
Und dieses vielleicht auch noch:
https://svnvsgit.com/