Verteilt oder Zentral?

[devtest]

Hallo,

ich habe leider noch nicht genau verstanden, wann es sinnvoll ist, ein Verteiltes System zu verwenden und in welchem Fall die Verwendung eines solchen Systems überhaupt keinen Sinn macht.

Mich interessieren vor allem die Nachteile eines Verteilten Systems.

Ich würde gerne in unserer Firma (mit ca. 7 Entwicklern am selben Standort) Subversion (welches ja ein Zentrales System ist) einführen und jetzt muss ich erklären, warum ein Verteiltes System eher nicht geeignet ist.

Danke für eure Antworten

[Christian Marquardt]

Ich verstehe nicht, was Subversion mit einem verteilten System zu tun hat....

[devtest]

Ich verstehe nicht, was Subversion mit einem verteilten System zu tun hat....

Ich auch nicht

Was ich im ersten Beitrag geschrieben habe, meine ich folgendermaßen:
Ich weiß, dass Subversion ein Zentrales System ist und da ich es einführen will, muss ich begründen, warum ich kein verteiltes System ausgewählt habe.

Alles was ich bis jetzt zu dem Thema gelesen habe, deutet darauf hin, dass in unserer Firma ein Zentrales System benötigt wird, gerade deshalb, weil die Zentrale Ablage der Quelltexte im Vordergrund steht.

[Christian Marquardt]

Was ich im ersten Beitrag geschrieben habe, meine ich folgendermaßen:
Ich weiß, dass Subversion ein Zentrales System ist und da ich es einführen will, muss ich begründen, warum ich kein verteiltes System ausgewählt habe.

Die Frage geht doch völlig am Sinn einer Versionsverwaltung vorbei bzw. hat damit nix zu tun?? Was für eine Versionsverwaltung "verteilt" die Daten?

Es stellt sich überhaupt nicht die Frage. SVN wird auf einem Server installiert, entsprechende Repositorys eingerichtet. Dann arbeiten alle Entwickler mit diesem Repositorys. Sie beziehen ihren Code daraus und checken ihren Code darin ein (wer einen nicht compilierbaren Head eincheckt, muss einen ausgeben...). Damit hat immer noch jeder Entwickler lokal seinen eigenen Code. Fertige Programmteile werden eingecheckt und stehen dann allen zur Verfügung

Wie soll ein verteiltes System arbeiten?

[Ralf Jansen]

Die Frage geht doch völlig am Sinn einer Versionsverwaltung vorbei bzw. hat damit nix zu tun?? Was für eine Versionsverwaltung "verteilt" die Daten?

Mercurial, Git etc. alles was im Moment Hip ist hat kein zwingendes zentrales Repository mehr. Und nebenbei gesagt sind diese Systeme auch Svn jederzeit vorzuziehen wenn man nicht gerade gegen Kollegen mit gewissen Beharrungskräften kämpfen muss Das wäre im Moment auch der einzige Grund den ich devtest nennen könnte bei svn zu bleiben oder svn neu einzuführen. Eben wenn alle beteiligten mit diesem Versionierungssystem Erfahrung haben und mit den Dingen die in den neuen Systemen besser gelöst wurden eh keine Probleme hatten.

Schöne Beschreibung für Umsteiger hier. Der Reeducationteil reicht aus um zumindest eine Vorstellung der Unterschiede zu bekommen wenn man svn kennt.

[Christian Marquardt]

Mercurial, Git etc. alles was im Moment Hip ist hat kein zwingendes zentrales Repository mehr.

Ok, dann ist das an mir völlig vorbei gegangen....

[Christian Marquardt]

hmmmm



zeigt, und so ist die Beschreibung auch da, dass es sehr wohl ein zentrales Repository gibt????

[Bernhard Geyer]

Die Frage geht doch völlig am Sinn einer Versionsverwaltung vorbei bzw. hat damit nix zu tun?? Was für eine Versionsverwaltung "verteilt" die Daten?

Es gibt auch verteilte Versionskontrollsysteme wie Mercurial.


Siehe auch: http://de.wikipedia.org/wiki/Versionsverwaltung

[Ralf Jansen]

zeigt, und so ist die Beschreibung auch da, dass es sehr wohl ein zentrales Repository gibt????

ja ... ich sagte aber nicht zwingend Du kannst ein eigene Topologie wählen die dir am besten passt. Und natürlich wird da üblicherweise auch ein Repository besonders ausgezeichnet weil man darauf z.b. dann ein explizit Backup machen möchte. Heißt in dem Bild ist Central Repository nicht anders als zum Beispiel Joel's Repository es ist nur logisch anders ausgezeichnet. An diesem wird eben nicht entwickelt sondern zum Beispiel nur gebackupped.

[Christian Marquardt]

Während bei Versionskontrollsystemen mit zentralem Server (wie CVS oder SVN) Dritte in der Regel nur lesenden Zugriff auf das Repository haben, wird bei Mercurial das Repository des Projektes, an dem man entwickeln will, „geklont“, also eine lokale Kopie erstellt. Auf dieser lokalen Kopie stehen dann die üblichen Funktionen zur Verfügung, beispielsweise das Erstellen neuer Revisionen, Change Set genannt.

?? Bei CVS oder SVN werden ebenfalls lokale Kopien eines Projektes erzeugt. Bei welcher Versionsverwaltung arbeitet man direkt mit dem zentralen Code. Der Unterschied ist wohl, dass ich lokal ebenfalls ein Repository habe, in dem ich Branches usw. anlegen kann. Wenn ich meine Code anderen zur Verfügung stellen will muss ich das trotzdem dem zentralen Repository zur Verfügung stellen.

Wo ist da ein markanter Unterschied? Weil es lokal "Repository" heisst und man dort diese Funktionalität hat? Nunja. Denke, dass es wohl immer eine Zentrale geben muss, über die man sich austauscht, sonst kann wohl eine Codeverteilung an Alle nicht sichergestellt werden?

[devtest]

Eben wenn alle beteiligten mit diesem Versionierungssystem Erfahrung haben und mit den Dingen die in den neuen Systemen besser gelöst wurden eh keine Probleme hatten.

Es ist vielleicht kaum zu glauben, aber bei uns wird seit Jahren ohne Versionsverwaltung entwickelt, weshalb die Entwickler wahrscheinlich wenig bis keine Erfahrung mit solchen Systemen haben.

Noch mal zur Frage: In welchem Fall ist es sinnvoll ein Zentrales System zu benutzen und wann ist ein Verteiltes System die bessere Wahl?
Ich habe gelesen, dass man diese beiden Konzepte nicht direkt vergleichen kann, da es auf das Einsatzgebiet ankommt. Ich habe auch den Eindruck, dass der Umgang mit einem Verteilten System komplizierter ist und hauptsächlich benötigt wird, wenn an unterschiedlichen Orten ohne Netzwerkverbindung entwickelt wird.
Aber da in unserem Fall sowieso alles Zentral abgelegt und gesichert werden soll, ist doch ein verteiltes System nicht wirklich nötig, wenn ich das richtig verstehe…

[Christian Marquardt]

Nachdem ich ein bissssschen gelesen habe:

IMHO stellt sich die Wahl nicht. Der sogenannte Vorteil von dezentralen Systemen ist, dass es keinen Unterschied mehr zwischen einem Client und einem Server gibt. Die Funktionalität die früher unter CVS/SVN der Server hatte (Branches, Tags) stehen auch auf dem Client zur Verfügung.
Wenn das jeder Entwickler braucht, ist das ein nützliches Feature.

Jedoch lösen die Systeme trotz dezentralem Aufbau nicht das Problem, dass immer irgendwo ein zentraler Platz benötigt wird, um den aktuellen Code (von den einzelnen Entwicklern als "fertig" gekennzeichent) abzulegen.
Mit welchem Code wird die Anwendung deployt?
Woher sollte ein "Neuer" seine Code bekommen? Ein Abgleich mit allen Clients?
Möglich, aber wenn einer der Clients nicht erreichbar (Entwickler aufgrund der Aufgabenstellung zusammengebrochen oder mit dem Notebook auf der Titanic) ist der Code dort "verloren". Also bleibt m.E. auch bei diesen Systemen nur die organisatorische Anweisung den fertigen Code immer mit einem zentralen Repository abzugleichen. Damit ist wenig gewonnen.
Gewonnen ist nur, dass der Client die Möglichkeit hat Funktionen einer Versionsverwaltung abzubilden.