Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › GVFS: Windows-Team nutzt…

Wieso bitte alles in ein Mega-Repo?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Wieso bitte alles in ein Mega-Repo?

    Autor: Tuxgamer12 26.05.17 - 15:23

    Sorry, aber der Sinn erschließt sich mir nicht.

  2. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: sg (Golem.de) 26.05.17 - 15:33

    Google und Facebook machen das intern übrigens auch, bei ähnlich riesigen Codebasen. Das halt wohl vor allem organisatorische Vorteile beim Entwickeln neuer Funktionen, bei denen sehr viele verschiedene Teile verändert werden müssen.

    Die lange Antwort findet sich im Blog von Microsoft:
    [blogs.msdn.microsoft.com]

    ---------
    Sebastian Grüner

    Golem.de

  3. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: Tuxgamer12 26.05.17 - 16:06

    Vielen Dank ;).

  4. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: Poison Nuke 26.05.17 - 17:17

    sg (Golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Google und Facebook machen das intern übrigens auch, bei ähnlich riesigen
    > Codebasen.

    Das Microsoft Repo ist ein Witz verglichen mit dem Repo von Goole. Selbst Facebook sein Repo ist winzig dagegen.

    Googles Repo umfasst(e) 86 TeraByte (vermutlich aktuell noch größer). Es ist mit gigantischem Abstand das größte Softwareprojekt auf der Welt, und mit 2 Milliarden Lines of Code sogar umfangreicher als sämtliche GitHub Repos zusammengefasst.

  5. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: amagol 26.05.17 - 17:49

    sg (Golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Google und Facebook machen das intern übrigens auch, bei ähnlich riesigen
    > Codebasen. Das halt wohl vor allem organisatorische Vorteile beim
    > Entwickeln neuer Funktionen, bei denen sehr viele verschiedene Teile
    > verändert werden müssen.

    Ich wuesste auch nicht worin der Vorteil bestehen sollte verschiedene Repository-Varianten in der selben Firma zu nutzen. Und wenn alles in z.B. Git ist, warum dann nicht auch alles in ein Repository? Das machen eigentlich alle grossen Firmen so (ausser fuer geheime Projekte, die oft erst nach dem Release in das Hauptrepository migriert werden).
    Die andere Sache ist dann, ob auf einem grossen Tree entwickelt wird oder ob man wie z.B. Maven Dependencies entkoppelt. Aus meiner Sicht ist der Big-Tree-Ansatz sinnvoller als die Dependency-Hoelle, auch wenn es schwieriger wird APIs komplett umzustellen, voraussetzung ist natuerlich dann ein virtuelles FS fuer den Client (sonst haette ich vermutlich mehrere PB Code auf der Platte ;) ).

  6. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: taifun850 26.05.17 - 17:54

    Ich sehe schon Gründe für eine Trennung in unterschiedliche Repos.

    Rechte kann man da nennen, aber auch eine klare Verantwortung für Schnittstellen. Bei einem großen Repo kann im Prinzip jeder eine komplette Schnittstelle ändern. Kompilieren mag es dann, aber inwieweit es noch das ist, was der Architekt mal haben wollte ist eine andere Frage.

    Die vielen Branches sind ein anderes Thema. Auch hier ist die Frage, wie man das wieder zusammen führen kann. Und wenn man das nicht will -> wieso dann alles in einem monolothischen Repo speichern?

  7. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: Hakuro 26.05.17 - 18:35

    Poison Nuke schrieb:
    --------------------------------------------------------------------------------
    > sg (Golem.de) schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Google und Facebook machen das intern übrigens auch, bei ähnlich
    > riesigen
    > > Codebasen.
    >
    > Das Microsoft Repo ist ein Witz verglichen mit dem Repo von Goole. Selbst
    > Facebook sein Repo ist winzig dagegen.
    >
    > Googles Repo umfasst(e) 86 TeraByte (vermutlich aktuell noch größer). Es
    > ist mit gigantischem Abstand das größte Softwareprojekt auf der Welt, und
    > mit 2 Milliarden Lines of Code sogar umfangreicher als sämtliche GitHub
    > Repos zusammengefasst.

    Das hört sich dramatisch gigantisch an - von der reinen Anzahl der Files ist es das auch, man sollte aber auch dabei schreiben, dass Google wirklich alle Projekte und Services in dieses Repo packt. Dass das Projekt Repo von Microsoft Windows und Facebook dagegen klein ist, wundert dann auch nicht wirklich, wenn Google da neben seiner Suchmachine, Gmail, Youtube, Google+, dutzende Betriebssysteme und die 500 anderen Dienste und nochmal das 10-fache toter und eingestampfter Projekte drin rumfliegen hat. Ich würde das nicht als ein Softwareprojekt bezeichnen.



    1 mal bearbeitet, zuletzt am 26.05.17 18:37 durch Hakuro.

  8. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: Poison Nuke 26.05.17 - 20:05

    taifun850 schrieb:
    --------------------------------------------------------------------------------
    > Rechte kann man da nennen, aber auch eine klare Verantwortung für
    > Schnittstellen. Bei einem großen Repo kann im Prinzip jeder eine komplette
    > Schnittstelle ändern.

    Es gibt so schon ein paar Plugins für Git die Sub-Folder based permissions anbieten. GVFS bietet mit Sicherheit auch etwas diesbezüglich an. Und da man bei Git alles nachvollziehen und rückgängig machen kann, könnte ich mir auch vorstellen, dass das ein über verbale Berechtigungen gelöst ist... sprich wenn da jemand in Code rumfummelt der ihm nicht gehört und was er nicht hätte tun dürfen, dann bekommt er vom Chef eins auf den Deckel. Sehe nicht warum man das nochmal extra per Software unterbinden sollte.

  9. Re: Wieso bitte alles in ein Mega-Repo?

    Autor: Slartie 26.05.17 - 21:31

    Hakuro schrieb:
    --------------------------------------------------------------------------------
    > Das hört sich dramatisch gigantisch an - von der reinen Anzahl der Files
    > ist es das auch, man sollte aber auch dabei schreiben, dass Google wirklich
    > alle Projekte und Services in dieses Repo packt. e und die 500 anderen Dienste und nochmal das
    > 10-fache toter und eingestampfter Projekte drin rumfliegen hat. Ich würde
    > das nicht als ein Softwareprojekt bezeichnen.

    Wer hunderte nur periphär miteinander verwandte Dienste in ein Repo packt, der steckt vermutlich auch vollkommen schmerzfrei einen kompletten Abzug des Linux-Kernels in besagtes Repo, wenn er sowas wie Chrome OS oder Android starten möchte. Bzw. mehrere Abzüge davon, für jedes auf Linux basierende eigene System einen.

    Die reine Zahl Files oder LoC sagt daher nicht besonders viel über den tatsächlichen Umfang des “Mehrwertes“ aus, der in diesem Code steckt - dafür müsste man wissen, wie viel originärer Google-Code und wie viel Code aus irgendwelchen Open-Source-Projekten konkret drin steckt. Noch weniger sagt die Größe in Giga- oder Terabytes. Wenn ich es zur Politik erhebe, wirklich alles in dieses Repo zu schieben, was ein Projekt braucht, dann gehören da schnell auch ein paar Gigabytes an Binaries dazu - Entwicklungsumgebung, kompilierte Dependencies, irgendwelche Serveranwendungen, you name it.

    Es mag ja beeindruckend sein, wie diese Firmen diese riesigen Mengen organisieren. Noch beeindruckender fände ich es aber, wenn sie die Komplexität nicht primär durch irrsinnig viel Hardware und Speicherplatz, sondern intelligente Modularisierung und Organisation ihrer Softwarearchitektur und Entwicklungs-Workflows lösen würden. Meiner persönlichen Erfahrung nach ist das nämlich erheblich schwerer...

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. OBI Group Holding SE & Co.KGaA, Köln
  2. Robert Bosch GmbH, Leonberg
  3. Dataport, Hamburg
  4. Bechtle Onsite Services GmbH, Weissach nahe Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 34,49€
  2. 169,99€ bzw. 15€ günstiger bei Newsletter-Anmeldung


Haben wir etwas übersehen?

E-Mail an news@golem.de


Montagewerk in Tilburg: Wo Tesla seine E-Autos für Europa produziert
Montagewerk in Tilburg
Wo Tesla seine E-Autos für Europa produziert
  1. Elektroauto Walmart will den Tesla-Truck
  2. Elektrosportwagen Tesla Roadster 2 beschleunigt in 2 Sekunden auf Tempo 100
  3. Elektromobilität Tesla Truck soll in 30 Minuten 630 km Reichweite laden

Fitbit Ionic im Test: Die (noch) nicht ganz so smarte Sportuhr
Fitbit Ionic im Test
Die (noch) nicht ganz so smarte Sportuhr
  1. Wii Remote Nintendo muss 10 Millionen US-Dollar in Patentstreit zahlen
  2. Ionic Fitbit stellt Smartwatch mit Vier-Tage-Akku vor

E-Golf im Praxistest: Und lädt und lädt und lädt
E-Golf im Praxistest
Und lädt und lädt und lädt
  1. Garmin Vivoactive 3 im Test Bananaware fürs Handgelenk
  2. Microsoft Sonar überprüft kostenlos Webseiten auf Fehler
  3. Inspiron 5675 im Test Dells Ryzen-Gaming-PC reicht mindestens bis 2020

  1. Darpa: US-Militär will Pflanzen als Schadstoffsensoren einsetzen
    Darpa
    US-Militär will Pflanzen als Schadstoffsensoren einsetzen

    Robust, unauffällig und einfach einzusetzen: Die Darpa will Pflanzen genetisch so manipulieren, dass sie als Sensoren eingesetzt werden. Die natürlichen Sensoren sollen beispielsweise Bomben, biologische, chemische oder radioaktive Kampfstoffe erkennen.

  2. Snpr External Graphics Enclosure: KFA2s Grafikbox samt Geforce GTX 1060 kostet 500 Euro
    Snpr External Graphics Enclosure
    KFA2s Grafikbox samt Geforce GTX 1060 kostet 500 Euro

    Externe Gehäuse für Grafikkarten sind oft klobig, das Snpr External Graphics Enclosure von KFA2 ist eine Ausnahme. Darin steckt eine extrem kompakte Geforce GTX 1060, die der Hersteller für die Grafikbox entwickelt hat. Zudem ist der Preis ansprechend.

  3. IOS 11 und iPhone X: Das Super-Retina-Display braucht nur wenige Anpassungen
    IOS 11 und iPhone X
    Das Super-Retina-Display braucht nur wenige Anpassungen

    Das iPhone X bietet nicht nur neue Hardware. Auch der Umgang mit Apps verändert sich dank neuer Auflösung, neuem Bildformat und neuer Gesten. Wir sehen darin den wahren Grund für die Abschaffung der 32-Bit-Apps und zeigen, wie in der Vergangenheit umgestellt wurde.


  1. 12:56

  2. 12:30

  3. 11:59

  4. 11:51

  5. 11:45

  6. 11:30

  7. 11:02

  8. 10:39