nicht angemeldet
Moin!
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.
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.
Und die Verfügbarkeit eines Online-Zugangs schwankt durchaus!
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. 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.
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.
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.
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.
- Sven Rautenberg
Auge