Login
Newsletter
Werbung

Thema: Subversion 1.11 veröffentlicht

21 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von ManInTheMiddle am Mi, 31. Oktober 2018 um 14:30 #

Das wäre für mich das wichtigste fehlende Feature.

1
Von Donald Trumpet am Mi, 31. Oktober 2018 um 15:19 #

Leute bleibt bei git

1
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.

  • 1
    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 :D

    0
    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"

    • 0
      Von Anonymous Coward am Do, 1. November 2018 um 10:01 #

      Es ist bezeichnend, dass Du zwar mit Beleidigungen um dich wirfst, aber dennoch nicht die Frage beantwortest, wer den Quatsch noch braucht.

      • 0
        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.)

    0
    Von Nailhammer am Mi, 31. Oktober 2018 um 21:11 #

    If your only tool is a hammer then every problem looks like a nail.

    0
    Von MichaelK am Do, 1. November 2018 um 14:03 #

    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.

    • 0
      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.

      • 0
        Von MichaelK am Do, 1. November 2018 um 16:41 #

        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.

        • 0
          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).

          • 0
            Von MichaelK am Sa, 3. November 2018 um 10:00 #

            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.

        0
        Von Lord am Do, 1. November 2018 um 22:34 #

        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.

        • 0
          Von Ghul am Fr, 2. November 2018 um 16:29 #

          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.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung