Von linux-nutzer am Fr, 2. November 2018 um 12:58 #
Manchmal nein, manchmal ja. Abgesehen von dem Fall ohne Internet: Wenn ich meine Arbeit in kleinen Schritten festhalte, möchte ich nicht unbedingt jeden kleinen Schritt zum Server schieben, sondern alles mit einmal. Oder ich organisiere meine Commits vorm Pushen nochmal neu, weil ich meine 10 Mini-Commits dann lieber in einen bündele, der das gesamte implementierte Feature enthält.
Teamwerkzeug: Hängt vom Workflow ab. Wenn man immer alles in den Hauptentwicklungszweig commitet, dann geht's nicht anders. Wenn man aber mit Feature-Branches arbeitet und die dann immer in den Hauptentwicklungszweig mergt, dann kann das für die anderen Leute auch erstmal egal sein. Dann musst du nur in der Lage sein, Merge-Konflikte vernünftig beheben zu können und Entwickler haben, die auch ab und an mal miteinander darüber reden, was sie grad am Projekt machen. Ich erinnere mich hier aber daran, dass Merge-Konflikte beheben bei SVN immer Sackgang war. Das ist so einer der Gründe, warum niemand in meinen Bekanntenkreis SVN nachtrauert.
Zugriffsrechte/Datei in Bearbeitung: Mag sein, dass Git das nicht kann.
Teile vom Repository klonen: War schon länger als Problem bekannt, aber Microsoft waren da anscheinend die ersten, für die das so wichtig war, dass sie da 'ne Lösung gebaut UND öffentlich gemacht haben (wurde Pro Linux ja ausführlich drüber berichtet).
Ich sag ja auch nicht, dass Subversion besser ist oder keine Nachteile hat. Ich sag ja nur, dass es halt immer drauf ankommt.
Und subversion oder auch andere zentrale Versionsverwaltung sind ja nach wie vor im Einsatz. Beispielsweise bei FreeBSD (wobei die ihr Repository inzwischen auch in ein git-Repository geklont haben; aber die Entwicklung geht nach wie vor über subversion). clang (inzwischen der Standardcompiler bei FreeBSD) ist ebenfalls in einem subversion-Repository.
Manchmal nein, manchmal ja. Abgesehen von dem Fall ohne Internet: Wenn ich meine Arbeit in kleinen Schritten festhalte, möchte ich nicht unbedingt jeden kleinen Schritt zum Server schieben, sondern alles mit einmal. Oder ich organisiere meine Commits vorm Pushen nochmal neu, weil ich meine 10 Mini-Commits dann lieber in einen bündele, der das gesamte implementierte Feature enthält.
Teamwerkzeug: Hängt vom Workflow ab. Wenn man immer alles in den Hauptentwicklungszweig commitet, dann geht's nicht anders. Wenn man aber mit Feature-Branches arbeitet und die dann immer in den Hauptentwicklungszweig mergt, dann kann das für die anderen Leute auch erstmal egal sein. Dann musst du nur in der Lage sein, Merge-Konflikte vernünftig beheben zu können und Entwickler haben, die auch ab und an mal miteinander darüber reden, was sie grad am Projekt machen. Ich erinnere mich hier aber daran, dass Merge-Konflikte beheben bei SVN immer Sackgang war. Das ist so einer der Gründe, warum niemand in meinen Bekanntenkreis SVN nachtrauert.
Zugriffsrechte/Datei in Bearbeitung: Mag sein, dass Git das nicht kann.
Teile vom Repository klonen: War schon länger als Problem bekannt, aber Microsoft waren da anscheinend die ersten, für die das so wichtig war, dass sie da 'ne Lösung gebaut UND öffentlich gemacht haben (wurde Pro Linux ja ausführlich drüber berichtet).
Ich sag ja auch nicht, dass Subversion besser ist oder keine Nachteile hat.
Ich sag ja nur, dass es halt immer drauf ankommt.
Und subversion oder auch andere zentrale Versionsverwaltung sind ja nach wie vor im Einsatz.
Beispielsweise bei FreeBSD (wobei die ihr Repository inzwischen auch in ein git-Repository geklont haben; aber die Entwicklung geht nach wie vor über subversion).
clang (inzwischen der Standardcompiler bei FreeBSD) ist ebenfalls in einem subversion-Repository.