Login
Newsletter
Werbung

Thema: Microsoft verbessert Skalierbarkeit von Git

12 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Donald_Luck am Do, 18. Januar 2018 um 13:30 #

Wenn man sowas liest kommt die Frage auf ob man in ein Paralleluniversum abgedriftet ist.
Dann freut man sich.
Und dann liest man den Text nochmal und gibt den nicht konsumierten Drogen die Schuld.

[
| Versenden | Drucken ]
1
Von nasowas am Do, 18. Januar 2018 um 13:39 #

Der Artikel liefert nur die halbe Wahrheit. Die Nasen bei Microsoft mussten unbedingt, weil ihnen nichts besseres eingefallen ist, den gesamten Quellcode aller Windowsversionen in ein Repository packen. Das man mit der schrägen Herangehensweise Probleme bekommt war klar. Und genau diese Probleme wurden bei Microsoft durch den Einsatz eigener Software gelöst.
Die Originalnachricht von Microsoft selbst zu dem Thema treibt einem schon die Tränen in die Augen.

[
| Versenden | Drucken ]
  • 0
    Von LH_ am Do, 18. Januar 2018 um 19:37 #

    Das Problem zu großer Archive in diversen DVCS ist nicht neu, auch in der Spieleentwicklung tritt dieses Problem oft auf, weswegen dort auch Perforce als VCS sehr beliebt ist, welches hierfür Lösungen anbietet.
    Microsoft steht damit also nicht alleine da, zumal die Pflege eines gewachsenen, alten Quellcodes eben besondere Herausforderungen stellt.

    [
    | Versenden | Drucken ]
    0
    Von fvzcxv am Do, 18. Januar 2018 um 21:34 #

    Ich gebe dir ja prinzipiell recht und verwende selbst auch submodules. Alleine schon weil man dann das ChangeLog besser fürhren kann und die Module wieder verwendbar sind. Aber dennoch kann man es doch nicht schlecht finden, wenn Microsoft sich an git beteiligt und es für größere Reposisitories schneller macht. Auch kann ich mir den FS Ansatz als fuse gut vorstellen - für wen auch immer ;)

    [
    | Versenden | Drucken ]
    • 0
      Von who knows am Do, 18. Januar 2018 um 21:45 #

      GitVFS macht aus einem distributed VCS ein Serverabhängiges. Dem muss man wohl nichts mehr hinzufügen...

      who knows

      [
      | Versenden | Drucken ]
      • 0
        Von Falk am Fr, 19. Januar 2018 um 01:56 #

        Doch - dem ist sogar sehr viel hinzuzufügen. So ist das Thema auf keinem Fall klug erörtert.

        Du kannst weiterhin auschecken, bauen. Nun kannst du lokal branchen, ändern, nochmal bauen, modifizieren, commiten. Alles was du brauchst hast du nun auf der lokalen Platte und kannst ganz normal lokal arbeiten. Ohne dass du vorher planen musstest, was alles nötig ist. Und wenn du noch etwas mehr benötigst, dann kannst du es mit geringer Bandbreite nachholen. Viel weniger, als wenn du mit SVN alles ausgecheckt hättest. Wie du siehst, hat der hybride Ansatz doch Vorteile.

        Mag ja sein, dass man Projekte kleiner schneiden kann, vor allem die von der grünen Wiese. OK, ich verstehe es auch nicht, warum man sich so ein Riesen-Repo antut. Aber vernünftig klein werden die Repos wahrscheinlich auch bei Aufteilung nicht.

        Wenn man euch so liest, dann bekommt man das Gefühl, als ob bei MS nur Idioten wären.

        Auch wenn, Linux z.B. seit seinem Bestehen eigentlich immer sicherer war, als Windows, auch wenn MS gerne immer mal wieder das Gegenteil behauptet hatte und sich dann wieder schön blamiert hatte. Aber wer ist Marktführer? Wer überstand sogar solche Debakel wie Windows ME, Windows Vista oder gar Windows 8? Warum spielt nahezu kein "ernsthafter" Gamer auf Linux, wo doch die Architektur so überlegen sein soll? Warum läuft MS Office praktisch überall?

        Irgendwie ist der Abstand in den letzten Jahren eher größer als kleiner geworden. Auch wenn man mit Open Source gut im Web programmieren kann und auch gut Geld verdienen kann.

        [
        | Versenden | Drucken ]
        • 0
          Von M$ alles Idioten? keinesfalls! am Fr, 19. Januar 2018 um 07:48 #

          Bei M$ sind Marktstrategen am Werk, die an nichts anderem interessiert sind, als den Markt zu beherrschen. Das ist an den Produkten deutlich zu sehen. Es ist keine wirkliche Interoperabilität gewünscht. Und wenn dann wird nur in Einbahnrichtung, also hin zu Windows, entwickelt und niemals umgekehrt. Die Kompatibilität läßt zu wünschen übrig und allgemein anerkannte Standards werden ignoriert oder so verändert, daß eben nur alles in einem M$ Universum perfekt funktioniert. Das ist Teil der Strategie. Und ganz viele IT Manager fallen voll drauf rein und schränken sich und ihr Unternehmen ein. Zudem sind sie noch bereit dafür viel, viel Geld auszugeben. Das sind die wirklichen Idioten! M$ läßt sie schön für sich arbeiten.

          Das M$ Universum ist nicht mit der verteilten, weltweiten Community zu vergleichen. Und wieder haben wir den Fall, daß M$ anerkannte Standards, in diesem Falle Git, so modifiziert, daß M$ profitiert aber die Community nicht. Natürlich wird durch GitVFS die Basis von git kompromotiert. Scheißegal, M$ nützt es, die restlichen git User sind uninteressant.

          Es ist einfach zu beobachten, daß M$ bei der Open Source hauptsächlich als Schmarotzer auftritt und nur für den eigenen Profit arbeitet. Geben und nehmen, die Basis der Commuinity, reduziert sich bei M$ auf nehmen.

          [
          | Versenden | Drucken ]
          • 0
            Von Falk am Fr, 19. Januar 2018 um 09:29 #

            Mag alles sein. Nur wenn die ihr eigenes Produkt verwalten, dann hatte sicherlich nicht die Marketing-Abteilung das letzte Wort. Sofern ich den Artikel verstanden habe, hat MS einerseits an einigen Stellen Git beschleunigt, andererseits zusätzlich ein virtuelles Dateisystem geschaffen, was eine technische Lösung für deren Problem war. Benutzt du es nicht, kannst du wahrscheinlich immer noch ganz genauso klonen.

            Git musste für GVFS modifiziert werden. Die haben ihr GVFS aber unter eine sehr wenig kontrollierende Lizenz gestellt. Soweit ich weiß, sollte die kompatibel zur GPL sein, solange MIT mit MS und GVFS noch irgendwo erwähnt wird.

            Und wo ist das Problem, wenn die es intern so einsetzten? Wie geschrieben - ich gehe stark von aus, dass du immer noch auch normal klonen kannst. Und selbst wenn nicht - dann ist es ein neues Produkt, das halt inkompatibel zu git wäre. Ist ja nicht so, dass SVN und CVS das anders machen würden. Nur dass die nicht mit so großen Repos funktionieren würden. Offensichtlich haben die nichts davon geheim gehalten.

            Allerdings klar: Sollte es inkompatibel zu git sein, würde man sich - sofern man es benutzt - wieder in die Fänge von MS begeben, wenn sich dazu keine Community bildet, was bei einem MS-Produkt dann doch sehr unwahrscheinlich ist.

            Es ist also die Frage, ob die kompatibel bleibt, ob es sich als weitere Lösung durchsetzt, ob das VFS auf andere Systeme portiert wird und wie kompatibel es in Zukunft sein wird. Aber zumindest die Beschleunigungen haben git auch selbst geholfen (und helfen auch MS Geld zu sparen, wenn die ihr Produkt auch in Zukunft von git ableiten sollten).

            [
            | Versenden | Drucken ]
            0
            Von pataa am Fr, 19. Januar 2018 um 22:23 #

            Open Source erlaubt das die Software an eigene Wünsche angepasst werden kann. Ich kann jetzt kein Schmarotzertum seitens Microsoft erkennen. Sorry.

            [
            | Versenden | Drucken ]
          0
          Von who knows am Sa, 20. Januar 2018 um 09:32 #

          Du kannst weiterhin auschecken, bauen.
          Das ist korrekt.
          Nun kannst du lokal branchen, ändern, nochmal bauen, modifizieren, commiten. Alles was du brauchst hast du nun auf der lokalen Platte und kannst ganz normal lokal arbeiten. Ohne dass du vorher planen musstest, was alles nötig ist. Und wenn du noch etwas mehr benötigst, dann kannst du es mit geringer Bandbreite nachholen. Viel weniger, als wenn du mit SVN alles ausgecheckt hättest. Wie du siehst, hat der hybride Ansatz doch Vorteile.
          Wie ich sehe, hast Du das Konzept nicht verstanden. Vielmehr klingt Dein Text wie aus der Marketingfiebel abgeschrieben. Die Arbeit mit einem DVCS setzt explizit keine permanente Netzwerkverbindung voraus. Exakt dieser Vorteil geht mit Git-VFS verloren. Das kann keine Marketingabteilung der Welt schön reden.
          Was den wirtschaftlichen Erfolg von Microsoft angeht: Dort sind in erster Linie fachlich nicht versierte Endanwender oder „Entscheider“ betroffen. Ohne die Geburtshilfe durch IBM säße Bill Gates noch heute in seiner Garage. Und ohne die Anwendung unlauterer Mittel, für die Microsoft Strafzahlungen zu leisten hatte, die einen hiesigen Mittelständler vollständig ruiniert hätten, sähe die Marktverteilung wohl ebenfalls völlig anders aus. Dazu kommt heftigste Lobbyarbeit auf allen Ebenen, bis hin zu bezahlten Forenschreibern.

          who knows

          [
          | Versenden | Drucken ]
          • 0
            Von Falk am Sa, 20. Januar 2018 um 12:29 #

            Glaub mir, unter Kollegen werde häufig ich gefragt, wenn es um Git geht (natürlich von denen, für die das neu ist, denn so kompliziert ist Git nicht). Und wenn dir eine Meinung nicht passt, ist die inkompetent oder halt bezahlt von MS. Das wolltest du mir doch unterstellen. Wie bescheuert. Ansonsten - ich kann es nicht leiden, wenn mit wenig halbgaren Argumenten eine Diskussion beendet werden soll und die Leute mit der anderen Meinung auch noch diffamiert werden.

            Nochmal zum Inhalt: Natürlich - die Netzwerkverbindung ist notwendig, sofern du weitere Dateien erwischst. Aber eigentlich auch nicht, wenn du ein compiliertes Teilprojekt hast und es gebaut hast. Aber das will MS wahrscheinlich gar nicht erreichen.

            Hast du schon mal was von Lazy Operations gehört? Ja, mit GVFS wird git wieder zentralisiert, ist mit GVFS nicht mehr vollständig distributed. Wie geschrieben - die haben ihr Problem damit gelöst (bzw. ihr Problem verbessert). Die haben ein Versionsverwaltungssystem geschaffen, was halt für sie passt.

            Klar, die gehen davon aus, dass man auch danach noch eine Verbindung zum vollständig geklonten Branch hat. Aber das stellt ja heutzutage nicht mehr ein so großes Problem dar. Z.B. für ein Blame oder allgemein für das Ansehen einer alten Dateiversion wirst du eine Verbindung benötigen. Aber der Traffic sollte sich in Grenzen halten - genau das, was MS erreichen wollte. Die Geschwindigkeit sollte gegenüber normalen Git, SVN und Kollegen deutlich erhöht sein, sofern du nur Teile benutzt.

            Da die Änderungen offensichtlich nach Git geflossen sind, kannst du ja immer noch Branches komplett auschecken. Einfach das GVFS weglassen.

            Weißt du, ich mag es, wenn man Sachen technisch untersucht, nicht die ganze Zeit mit Ideologie geworfen wird. Ich selbst brauche das GVFS nicht. Ich mag es, wenn ich die Branches althergebracht vollständig auschecke. Warum auch bei den normalen Projektgrößen.

            [
            | Versenden | Drucken ]
            • 1
              Von who knows am Mo, 22. Januar 2018 um 00:34 #

              Glaub mir, unter Kollegen werde häufig ich gefragt, wenn es um Git geht (natürlich von denen, für die das neu ist, denn so kompliziert ist Git nicht). Und wenn dir eine Meinung nicht passt, ist die inkompetent oder halt bezahlt von MS. Das wolltest du mir doch unterstellen. Wie bescheuert. Ansonsten - ich kann es nicht leiden, wenn mit wenig halbgaren Argumenten eine Diskussion beendet werden soll und die Leute mit der anderen Meinung auch noch diffamiert werden.
              Offensichtlich ist es genau das, was Du mir jetzt zu unterstellen versuchst.
              Oprah wirbt für Surface und nuzt dazu ein Ipad
              - Nur mal so als Hinweis...

              Nochmal zum Inhalt: Natürlich - die Netzwerkverbindung ist notwendig, sofern du weitere Dateien erwischst. Aber eigentlich auch nicht, wenn du ein compiliertes Teilprojekt hast und es gebaut hast. Aber das will MS wahrscheinlich gar nicht erreichen.

              Hast du schon mal was von Lazy Operations gehört? Ja, mit GVFS wird git wieder zentralisiert, ist mit GVFS nicht mehr vollständig distributed. Wie geschrieben - die haben ihr Problem damit gelöst (bzw. ihr Problem verbessert). Die haben ein Versionsverwaltungssystem geschaffen, was halt für sie passt.
              Und hier liegt der Knackpunkt: Es passt für sie.

              Klar, die gehen davon aus, dass man auch danach noch eine Verbindung zum vollständig geklonten Branch hat. Aber das stellt ja heutzutage nicht mehr ein so großes Problem dar. Z.B. für ein Blame oder allgemein für das Ansehen einer alten Dateiversion wirst du eine Verbindung benötigen.
              Wenn Microsoft hier nicht komplett gepfuscht hat, so ist die Versionshistorie für die ausgecheckten Dateien vollständig vorhanden.

              Aber der Traffic sollte sich in Grenzen halten - genau das, was MS erreichen wollte. Die Geschwindigkeit sollte gegenüber normalen Git, SVN und Kollegen deutlich erhöht sein, sofern du nur Teile benutzt.
              Die Performanz ist auch dann erhöht, wenn man das Repositorium in handlichen Stücken verwaltet. Klar bestehen immer noch Abhängigkeiten, aber die beziehen sich bei einem modular aufgebauten System immer auf eine feste Revision - den nächsten Releasekandidaten. Dafür gibt es dann tags. Das Arbeiten auf den HEADS der Abhängigkeiten, die ja auch in permanenter Entwicklung sind, macht es fast unmöglich, vernünftig zu testen. Möglicherweise beruht darauf die legendäre „Qualität“ Microsoftscher Produkte...

              Da die Änderungen offensichtlich nach Git geflossen sind, kannst du ja immer noch Branches komplett auschecken. Einfach das GVFS weglassen.
              Das brauche ich nicht, da Git-VFS - fälschlicherweise auch als GNOME-VFS (GVFS) bezeichnet - nur auf Windows 10 läuft...

              Weißt du, ich mag es, wenn man Sachen technisch untersucht, nicht die ganze Zeit mit Ideologie geworfen wird. Ich selbst brauche das GVFS nicht. Ich mag es, wenn ich die Branches althergebracht vollständig auschecke. Warum auch bei den normalen Projektgrößen.
              Weißt Du, ich mag es, wenn man technische Dinge auf elegante Art löst und dabei auch den Rest der Welt im Auge behält. Ein Ansatz wie Git-VFS um damit Hinweise zu erarbeiten, wie man ein offensichtlich missgestaltetes Repositorium in eine wohlgefällige Form bringen kann, wäre tatsächlich eine Bereicherung für jedes Versionsverwaltungstool. Denn dass im Hause Microsoft noch irgend jemand den Überblick über ein in Jahrzehnten gewachsenes Softwarekonglomerat hat, wage ich doch zu bezweifeln. Darüber hinaus wäre ein solches Tool auch für den Einen oder Anderen außerhalb des Konzerns von Nutzen. Aber dafür würde Microsoft dann sicherlich Geld verlangen...
              An dieser Stelle weise ich explizit darauf hin, dass die Verwendung von git kostenlos ist.

              who knows

              [
              | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung