Versionierungssoftware -> Subversion, Git, CVS

[dedlfix]

Hi!

Muss man für solche dezentralen Systeme immer einen Daemon/Dienst laufen haben, sowie eine bekannte IP-Adresse besitzen, damit sich andere verbinden können? Wie ist es mit Arbeiten hinter Firewalls, über die man noch dazu keine administrative Gewalt hat, beispielsweise wenn man in einem Unternehmen sitzt, das einen Internetzugriff nur über Proxy gestattet?
Das Argument gilt doch umso mehr für zentrale Systeme.
Gerade bei einem zentralen Server wie SVN sind die obigen Punkte kein Thema.
Das siehst du falsch.

Aber was daran falsch ist, kann ich in deiner Antwort nicht erkennen.

Der Server ist irgendwo stets erreichbar, dessen Adresse ist bekannt und er kann normalerweise auch über einen Proxy angesprochen werden. Der Punkt war, ob sich die dezentralen Systeme ebenso leicht erreichen lassen. Und ob man statt einem Server mit einem offenen Port nun viele Server mit je einem offenen Port betreiben muss - inklusive dem Einrichten von Portforwarding hinter Routern.
Halten wir fest: OHNE Zugang zum zentralen SVN-Server kann man mit SVN nicht arbeiten. Ohne Zugang zu einem als zentral definierten Git-Server kann man aber sehr wohl arbeiten.

Ohne Zugang zu einem zentralen Server kann ich genauso gut, schlecht oder gar nicht arbeiten wie ohne Zugang zu einem dezentralen Server, nämlich nur mit dem Zeug, was bereits auf meiner Platte ist oder eben fehlt. Einzig privates Versionieren ist bei einem verteilten System ohne Zugang zu anderen Servern zusätzlich möglich.

Was ist mit den netzwerktechnischen Argumenten?

Und die Verfügbarkeit eines Online-Zugangs schwankt durchaus!

Eine Alles-und-Nichts-Aussage.

Bei zentralen Systemen muss immer der zentrale Punkt erreichbar sein, egal was man tut.
Wenn ich den aktuellen Stand haben möchte, muss auch einer der dezentralen Punkte erreichbar und aktuell sein. Die Frage war, ob man in meinem Szenario vom dezentralen System irgendeinen Vorteil hat oder eine Infrastruktur wie beim zentralen System benötigt.
Der dezentrale Punkt liegt auf der eigenen Platte.

Das tut er ja nicht aus heiterem Himmel sondern muss erste einmal dorthin gelangen und irgendwann auch wieder zurück zu den anderen.

Dorthin kann ich mir alle Entwicklungszweige der Mitarbeitenden zusammenziehen und lokal so arbeiten, als wäre ich mit dem zentralen Server verbunden. Ich muss aber kein einziges Byte online versenden, um so arbeiten zu können, d.h. ich kann mir dann, wenn ich online bin, alle anderen Entwicklungszweige holen.

Gilt vor allem für's Versionieren. Ich bin aber nicht komplett arbeitsunfähig, wenn ich bei einem zentralen System grad keinen Zugang habe. Arbeiten kann man schon, nur eben nicht versionieren.

Bei dezentralen Systemen wie git kann ich lokal arbeiten, wenn der zentrale Punkt (z.B. der "Hauptentwicklungszweig", an dem sich alle Teilbäume wieder vereinigen (sollen)) nicht verfügbar/erreichbar ist.
Da hab ich aber keinen aktuellen Stand.
Es gibt ja auch nicht "den aktuellen Stand" in einem verteilten Entwicklungssystem. Und die neuesten Entwicklungen und Commits in den Zweigen der Mitarbeitenden interessieren in der Regel auch nicht, solange diese nicht freigegeben und in die aktuelle Codebasis eingearbeitet wurden.

Also gibt es den aktuellen offiziellen Stand und viele nicht freigegebene.

Man kann vielleicht weiterarbeiten, wenn man Arbeitsteilung hat und wenigstens der von einem selbst bearbeitete Teil lokal verfügbar ist. Das war in meinem Szenario nicht gegeben. Dazu bräuchte man einen Laptop oder nur einen Arbeitsort.
Git ist darauf ausgelegt, lokal zu arbeiten und obendrein noch gut strukturierte Netzwerkkommunikation zur Codeverteilung anzubieten.

Schön, wenn man es braucht. Und wenn nicht? Ist es dann trotzdem immer noch uneingeschränkt empfehlenswert?

Subversion _kann_ das Repository auch lokal ablegen, aber das war's dann auch, damit ist man festgelegt auf genau diesen einen Ort des Repositories. Lokal arbeiten und optional mit anderen Servern, das geht mit Subversion nicht.

Ein verteiltes System hat also Vorteile, wenn man die Arbeit unter mehreren Leuten aufteilen will. Ihr weicht aber aus und beschreibt immer wieder nur Vorteile beim Arbeiten mit mehreren Personen. Warum bewertet ihr nicht mal die Eigenschaften eines dezentralen Systems für das von mir aufgeführte Szenario? Auch wurden die obigen Fragen noch nicht beantwortet.

Lo!