Wenn jetzt ein scriptkiddie etwas coded was nicht ganz so astrein ist und es committet hat er es erstmal lokal. Pusht er es zu einem Entwickler kann der nochmals drübersehen und gegebenenfalls korrigieren bevor er es dann an die cracks und scripter weiterleitet. Einer der Cracks schautnochmals drüber, ändert vielleicht noch kleinigkeiten und verteilt das ganze weiter an seine Homies.
Und letztendlich pullt linus Änderungen aus seinem "Kreis des Vertrauens" bevor er ein neues release rausgibt.
Und das ist das was du mit einem SVN so nicht hinbekommst.
Alle haben gleichberechtigte Versionen, aber ziehst du dir einen Linuxkernel lieber von Linus oder von Heinz Kunz aus Niederdupfingen?
Du kannst einen zentralen Server hernehmen, der ist zwar gleichberechtigt wie alle anderen, per konvention aber kann man festlegen das dies der master ist.
Warum benötigst du unbedingt locks. Du kannst genauso mergen wie mit cvs oder svn.
Ich finde es eher so das bei svn und cvs jeder commit gleichberechtigt ist, bei verteilten Systemen holt man sich die Änderungen aus Quellen denen man vertraut.
Wie funktioniert denn bei SVN das Branchen?
Und nun stell dir vor das bei SVN der Server schlapp macht. Oder kein Netz zur Verfügung steht.
OK, das hieße aber doch, dass das Scriptkiddie seinen Code in das Repository vom Entwickler draufschiebt. Damit er da nochmal drübergucken kann. Das bedeutet doch, das unzählige Kiddies das machen können. Ich hätte jetzt gesagt, dass einen Entwickler das doch krank machen muss, wenn er jeden Tag, um mit seinem Repo überhaupt arbeiten zu können, zig Änderungen von den Kiddies erst einmal rückgängig machen muss wenn diese nichts taugen. Es sei denn natürlich, es gibt eine spezielles "Dump"-Repo, worauf niemand wirklich arbeitet, sondern das nur dafür da ist zu prüfen ob alle übermittelten Änderungen auch wirklich funktionieren. DAS wäre aber doch dann wieder das Modell des dedizierten Servers.
Als Antwort auf deine Frage, was passiert wenn so ein Server im SVN ausfällt... also wenn das ähnlich ist wie bei MKS, hat jeder Entwickler seine Sandboxes mit den Projekten/Subprojekten, die er bearbeitet und kann ganz normal weiterarbeiten. Nur kann er diese Änderungen noch nicht auf den Server spielen solange er down ist. Er kann aber sicher sein, dass kein andere etwas an diesen Sourcen ändern kann, da ka der Server für alle down ist und er das Lock auf den Files hatte bevor der Server wegfiel. Heißt nur er hat das schreibrecht auf diese Dateien.
Und Branches funktionieren ähnlich. Jeder User, der das System Recht zum branchen hat, kann diese Anlegen. Meistens haben die direkten Vorgesetzten dieses Recht damit nicht jeder User einen neuen Branch aufmachen kann. Das gäb nur Wildwuchs.
Du sagtest
Alle haben gleichberechtigte Versionen, aber ziehst du dir einen Linuxkernel lieber von Linus oder von Heinz Kunz aus Niederdupfingen?
Das finde ich etwas unverständlich. Im ersten Teil des Satzes sagst du, dass ALLE gleichberechtigte Versionen haben. Dann fragst du von wo man lieber nen Linux Kernel ziehen würde. Was hindert denn "Heinz Kunz" daran seine Codechanges nicht einfach direkt auf Linus' Repo zu pushen? Sind diese Changes immer erst in Quarantäne bis der Besitzer des Repos die freischaltet?
Nicht falsch verstehen. Ich würde gerne Git nutzen, gerade da es ohne Server auskommt. Ich fänd es gut mit Freunden ein Hobby Projekt aufzusetzen, die weiter weg wohnen. Man spricht also nicht sehr häufig und daher wär es wichtig, dass jeder auf der selben CodeBase arbeitet.
Nur irgendwie stelle ich mir das sehr schwierig vor. Mal stelle sich nur einmal ein recht kleines Projekt vor. Sagen wir wirklich mal nur ein Program, welches aus einem MVC besteht. Also, 1 Klasse Model, eine Klasse View, eine Klasse Controller. Wirklich sehr kompakt. Wenn man nun zu dritt daran arbeiten möchte und jeder das volle Repository als gleichberechtigte Version auf der Platte hat, wie genau funktioniert die Change Propagation? So wie ich das verstehe kann jeder bei seiner Entwicklung einzelne Stände für sich committen. Und er kann diese Änderungen zu jemand anderes pushen.
Muss man sich also immer absprechen wer wohin pusht? Also immer "A pusht nach B und C, B pusht nach A und C, C pusht nach A und B"?.
Das müsste dann am Ende jeden Arbeitstages gemacht werden, damit am folgenden Tag jeder die aktuellsten Sourcen auf der Platte hat.
Ich wüsste wie dies mit einem Serversystem wie MKS zu lösen ist. Projekt liegt auf dem Server, jeder erzeugt sich eine Sandbox auf der Festplatte und kann arbeiten. In der MKS GUI sieht man auch sofort, wer welche Datei derzeit in Bearbeitung hat. Und man bekommt ein Delta Icon an den Sourcen angezeigt, sobald man einen veralteten Stand einer Datei auf der Platte hat. Dann weiß man, es gibt etwas neues. Man macht einen snyc und man hat die aktuellste Version. Sollte dann etwas auf einmal nicht mehr funktionieren, stellt man die "Working Revision" von der Head Revision wieder zurück auf die vorherige Version und teilt dem anderen Entwickler mit, dass da in seinen Änderungen etwas nicht passen kann.
Mich würde wirklich interessieren, wie eine Entwicklung mit Git ablaufen würde. Im Internet habe ich bisher immer nur how to's gefunden, die zwar die Mechanik etc behandeln, aber nie etwas beispielhaft beschreiben. z.b wie mehrere Entwickler CodeChanges an einander verteilen und das jeder Entwickler jederzeit einen kosistenten Stand des gemeinsam entwickelten Projektes hat. Vielleicht nicht unbedingt das Linux Beispiel. Das scheint mir mittlerweile so Professionell, dass man daran nicht unbedingt ableiten könnte, wie man das selber mit 3-8 Entwicklern ohne einen "Übervater, der alles absegnet" nachahmen könnte.
