Von Anonymous Coward am Mi, 31. Oktober 2018 um 19:55 #
Das Problem Versionskontrolle ist gelöst, die Lösung heißt git. Möglich, dass irgendwann eine bessere Lösung daherkommt, aber Subversion wird das nicht sein. Ich verstehe ehrlich gesagt nicht, wieso jemand sein Leben damit verschwendet, noch an diesem Zombie herumzuschrauben.
Von Anonymous Coward am Mi, 31. Oktober 2018 um 20:07 #
Ein echter Lacher sind übrigens die FAQ. Zitat: „I run Apache 1.x right now, and can't switch to Apache 2.0 just to serve Subversion repositories. Does that mean I can't run a Subversion server?“
Offenbar wendet man sich an eine Klientel, denen Apache 2.0 (erschienen 2002) einfach zu bleeding edge ist
Von Verfluchtnochmal_5987109 am Mi, 31. Oktober 2018 um 20:50 #
Lass du Witzfigur doch die Lösung für Probleme deren Sorge sein welche sie haben! Es gibt in vielen Umgebungen schlichtweg keinen Bedarf von subversion weg zu migrieren selbst wenn man im Falle dass es damals GIT schon gegeben hätte halt selbiges benutzen würde
Idioten wie du klingen nach "Habe Lösung und suche nun Problem"
Von blablabla233 am Sa, 3. November 2018 um 13:14 #
Den Quatsch braucht der, der ihn noch nutzt....verstanden? Git ist ein schlechter und grosser hack geworden (nicht der "core")...mir passt bitkeeper um einiges besser (nur schon wegen der liz.)
Das Problem Versionskontrolle ist gelöst, die Lösung heißt git. Möglich, dass irgendwann eine bessere Lösung daherkommt, aber Subversion wird das nicht sein. Kann man so nicht sagen. git und subversion haben verschiedene Ansätze. In manchen Szenarien ist git besser. In anderen subversion.
Von linux-nutzer am Do, 1. November 2018 um 14:46 #
Welche Fälle wären das bei Subversion?
Für mich hat Subversion schon verloren, weil es ein zentralisiertes und kein verteiltes VCS ist. In einem Git-Repo kann ich auch dann fröhlich committen, wenn der Server down ist oder ich grad kein Internet hab. Bei SVN geht das nicht.
In einem Git-Repo kann ich auch dann fröhlich committen, wenn der Server down ist oder ich grad kein Internet hab Die Frage ist ja dann: Will man dann auch commiten? Wenn man Versionsverwaltung als Teamwerkzeug sieht, nutzen lokale Commits ja nur begrenzt etwas, da die anderen Teammitglieder davon erst mal nix haben.
Ebenso fehlt dann prinzipbedingt die Möglichkeit Zugriffsrechte festzulegen oder auch einfach Dateien als "in Bearbeitung" zu markieren. Denn nicht immer ist ein Merge einfach zu realisieren. Insbesondere bei Binärdateien (wie z.B. Bilder).
Das ganze Repository zu klonen ist auch umständlich, wenn man nur ein Teil davon braucht.
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.
Geht bei SVN genauso kannst ja ein local file repo machen. Ich glaube eher, du hast keine Ahnung von SVN, willst aber mitreden.
SVN hat diverse Vorteile, besseres Rechtemanagement, einfach lesbare Revisionsnummern, Teilcheckouts , Storage Größe. Ganz große Repos sind ein Problem in Git (Linux kernel ist kein großes Repo) weil du dann als Nutzer eine genauso große Platte bräuchtest. Ich betreibe SVN repos die voll ausgecheckt mehrere TB groß sind, ist aber kein Problem, weil niemand das komplett auschecken kann/darf/muss etc. könnte man mit Git gar nicht umsetzen.
Von daher, mit Halbwissen sollte man nicht hausieren gehen.
Ich betreibe SVN repos die voll ausgecheckt mehrere TB groß sind, ist aber kein Problem, weil niemand das komplett auschecken kann/darf/muss etc. könnte man mit Git gar nicht umsetzen.
In welchem Bereich soll das sein? Quellcode braucht normalerweise keine TB an Daten. Ist das ein Computerspiel mit Grafiken oder eine ganz andere Branche? Wenn ersteres zutreffen sollte, wäre es sinnvoll, den Code in einem eigenen Repo zu halten.
Das Problem Versionskontrolle ist gelöst, die Lösung heißt git. Möglich, dass irgendwann eine bessere Lösung daherkommt, aber Subversion wird das nicht sein. Ich verstehe ehrlich gesagt nicht, wieso jemand sein Leben damit verschwendet, noch an diesem Zombie herumzuschrauben.
Ein echter Lacher sind übrigens die FAQ. Zitat: „I run Apache 1.x right now, and can't switch to Apache 2.0 just to serve Subversion repositories. Does that mean I can't run a Subversion server?“
Offenbar wendet man sich an eine Klientel, denen Apache 2.0 (erschienen 2002) einfach zu bleeding edge ist
Lass du Witzfigur doch die Lösung für Probleme deren Sorge sein welche sie haben! Es gibt in vielen Umgebungen schlichtweg keinen Bedarf von subversion weg zu migrieren selbst wenn man im Falle dass es damals GIT schon gegeben hätte halt selbiges benutzen würde
Idioten wie du klingen nach "Habe Lösung und suche nun Problem"
Es ist bezeichnend, dass Du zwar mit Beleidigungen um dich wirfst, aber dennoch nicht die Frage beantwortest, wer den Quatsch noch braucht.
Den Quatsch braucht der, der ihn noch nutzt....verstanden?
Git ist ein schlechter und grosser hack geworden (nicht der "core")...mir passt bitkeeper um einiges besser (nur schon wegen der liz.)
If your only tool is a hammer then every problem looks like a nail.
Das Problem Versionskontrolle ist gelöst, die Lösung heißt git. Möglich, dass irgendwann eine bessere Lösung daherkommt, aber Subversion wird das nicht sein.
Kann man so nicht sagen. git und subversion haben verschiedene Ansätze. In manchen Szenarien ist git besser. In anderen subversion.
Welche Fälle wären das bei Subversion?
Für mich hat Subversion schon verloren, weil es ein zentralisiertes und kein verteiltes VCS ist. In einem Git-Repo kann ich auch dann fröhlich committen, wenn der Server down ist oder ich grad kein Internet hab. Bei SVN geht das nicht.
In einem Git-Repo kann ich auch dann fröhlich committen, wenn der Server down ist oder ich grad kein Internet hab
Die Frage ist ja dann:
Will man dann auch commiten?
Wenn man Versionsverwaltung als Teamwerkzeug sieht, nutzen lokale Commits ja nur begrenzt etwas, da die anderen Teammitglieder davon erst mal nix haben.
Ebenso fehlt dann prinzipbedingt die Möglichkeit Zugriffsrechte festzulegen oder auch einfach Dateien als "in Bearbeitung" zu markieren.
Denn nicht immer ist ein Merge einfach zu realisieren. Insbesondere bei Binärdateien (wie z.B. Bilder).
Das ganze Repository zu klonen ist auch umständlich, wenn man nur ein Teil davon braucht.
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.
Geht bei SVN genauso kannst ja ein local file repo machen. Ich glaube eher, du hast keine Ahnung von SVN, willst aber mitreden.
SVN hat diverse Vorteile, besseres Rechtemanagement, einfach lesbare Revisionsnummern, Teilcheckouts , Storage Größe. Ganz große Repos sind ein Problem in Git (Linux kernel ist kein großes Repo) weil du dann als Nutzer eine genauso große Platte bräuchtest. Ich betreibe SVN repos die voll ausgecheckt mehrere TB groß sind, ist aber kein Problem, weil niemand das komplett auschecken kann/darf/muss etc. könnte man mit Git gar nicht umsetzen.
Von daher, mit Halbwissen sollte man nicht hausieren gehen.
In welchem Bereich soll das sein?
Quellcode braucht normalerweise keine TB an Daten.
Ist das ein Computerspiel mit Grafiken oder eine ganz andere Branche?
Wenn ersteres zutreffen sollte, wäre es sinnvoll, den Code in einem eigenen Repo zu halten.
dann kann man auch gleich perforce nehmen